https://wiki.freifunk-franken.de/mediawiki/api.php?action=feedcontributions&user=Green&feedformat=atom
Freifunk Franken - Benutzerbeiträge [de]
2024-03-28T17:57:06Z
Benutzerbeiträge
MediaWiki 1.40.1
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Portal:Netz&diff=6624
Portal:Netz
2016-05-19T17:15:23Z
<p>Green: /* Statische IP-Adressen */</p>
<hr />
<div>== Das Netz ==<br />
Eine Karte der aktiven Router gibt es [https://monitoring.freifunk-franken.de/map].<br />
<br />
Eine Karte der Hoods ist [http://keyserver.freifunk-franken.de/fff/voronoimap.php hier] zu finden.<br />
<br />
Die [https://monitoring.freifunk-franken.de/routers Liste der Router] kann dank Monitoring immer live verfolgt werden. Infos über die Schreibweise (z.B. "/20") gibt es in der [http://de.wikipedia.org/wiki/CIDR Wikipedia].<br />
<br />
=== Gateway ===<br />
Erste Versuche einer sinnvollen Aufteilung von Gateways. Erweiterungen und Verbesserungen sind jederzeit erwünscht. [https://pad.freifunk.net/p/Gatewayaufteilung-Franken Zum Pad]<br />
<br />
== IP-Netz ==<br />
Mit der Netz-Umstellung vom 22.03.2014 haben wir nicht mehr länger ein großes [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_2_.E2.80.93_Sicherungsschicht_.28Data_Link_Layer.29 Layer-II-Netz], welches durch das [https://de.wikipedia.org/wiki/B.A.T.M.A.N. B.A.T.M.A.N. advanced]-Protokoll geroutet wird. Seitdem gibt es mehrere [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_3_.E2.80.93_Vermittlungsschicht_.28Network_Layer.29 Layer-III-Netze] (Hoods). Ein Layer-III-Netz entsteht grundsätzlich, indem hier ein Subnetz eingetragen wird. Wie dabei genau vorgegangen wird, steht in [[HoodVerwaltung]].<br />
Für jedes Subnetz muss separat abgewogen werden, wie groß es werden wird und wo es dann in die bestehenden Subnetze am besten eingegliedert werden kann.<br />
<br />
==== DHCP ====<br />
[[Datei:Hoods.png|200px|thumb|right|Vorschlag für die Hood-Organisation]]<br />
Damit simple Clients das neue Subnetz nutzen können, muss ein eigener DHCP-Server pro Subnetz bereit gestellt werden. Es macht dabei häufig Sinn, das Subnetz in IP-Bereiche aufzuteilen, die von mehreren DHCP-Servern verteilt werden. Ein zweiter DHCP-Server ermöglicht zum einen eine Lastverteilung, zum anderen erhöht sich die Ausfallsicherheit. Der DHCP-Server muss den Clients ein Default-Gateway und mindestens einen DNS-Server zuweisen. Da das Default-Gateway ebenfalls innerhalb des Subnetzes liegen muss, bietet es sich an, den selben Server, auf dem das DHCP läuft, zu nutzen.<br />
<br />
==== OLSR-Router ====<br />
Das Subnetz muss anschließend an das vorhandene Freifunknetz angeschlossen werden. Dazu muss eine Verbindung zu einem bestehenden OLSR-Router aufgebaut werden. Dies kann eine VPN-Verbindung, aber auch eine Wifi-Verbindung sein und muss individuell zwischen den zwei Parteien ausgehandelt werden. Es kann sinnvoll sein, Verbindungen zu mehr als einem OLSR-Router zu haben. Sobald der eigene Router an das OLSR-Netz angebunden ist, ist er selbst ein OLSR-Router.<br />
<br />
An den eigenen OLSR-Router können nun Accesspoints angeschlossen werden. Dies kann per VPN, WLAN, Kabel oder anderweitig geschehen. Es ist auch möglich, den Accesspoint selbst als OLSR-Router anzubinden. Auch diese Konfiguration ist individuell zu klären. Ein Accesspoint kann ein (oder mehrere) einfacher Wifi-AP oder auch ein Array von mehreren B.A.T.M.A.N.-Knoten sein. Es sollte vermieden werden, dass sich Subnetze vermischen. Dies würde immer dann passieren, wenn zwei Layer-II-Netze, die eigentlich unterschiedliche Subnetze verteilen, verbunden werden. Besonders beim B.A.T.M.A.N.-Protokoll besteht hier leicht diese Gefahr; daher sollte für jedes Subnetz eine eigene BSSID und ESSID gewählt werden.<br />
<br />
==== Aus Routersicht ====<br />
Nur Router in einer Hood können sich per B.A.T.M.A.N. advanced vermaschen, sowohl per VPN, also auch per WLAN. Daher müssen Router die räumlich nahe beieinander stehen auch in derselben Hood sein. Durch das Vermaschen des Netzes wird allerdings auch Verwaltungs-Verkehr erzeugt (Overhead). Je größer die Hood, desto größer der Overhead.<br />
<br />
Eine Verbindung zwischen Routern in unterschiedlichen Hoods ist per IP (OSI Schicht 3) möglich.<br />
<br />
Wenn im Netmon kein Standort eingegeben wurde, dann landet der Router in der Dafault-Hood.<br />
<br />
==== Monitoring (Netmon) ====<br />
Aktuell können sich Knoten nur über ein IPv6-Link-Local-Interface beim Netmon anmelden und Netmon kann die Knoten nur über eine IPv6-Link-Local-Adresse abfragen. Hier muss ein neuer Mechanismus gefunden werden, der es ermöglicht, die Knoten über Subnetze hinweg anzusprechen.<br />
<br />
Als Workaround ist es möglich, über einen Layer-II-Tunnel zum Netmon-Server das Subnetz an das Netmon anzubinden. Auf dem Netmon-Server werden alle Subnetze in einem Bridge-Interface zusammengefasst, welches keine Pakete weiterleiten kann.<br />
<br />
==== Wireless-LAN ====<br />
Wir haben uns auf folgende WLAN-Parameter verständigt:<br />
'''ESSID: franken.freifunk.net'''. Kanal 1.<br />
<br />
== Liste der Subnetze ==<br />
<br />
=== 10.50.0.0/16 ===<br />
<br />
{|<br />
! !! Bereich !! Bereitgestellt durch<br />
|-<br />
! 10.50.0.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.0.1 – 10.50.15.254</font> || <br />
|-<br />
! 10.50.16.0/20 || Default Hood ||<br />
|-<br />
| || 10.50.16.1 – 10.50.17.255 || Statische Adressen<br />
|-<br />
| || 10.50.18.0 – 10.50.19.255 || --<br />
|-<br />
| || 10.50.20.0 – 10.50.21.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey">10.50.22.0 – 10.50.23.254 </font> || <br />
|-<br />
| || <font color="grey">10.50.24.0 – 10.50.31.254 </font> || <br />
|-<br />
! 10.50.32.0/21 || Fürth Hood ||<br />
|-<br />
| || 10.50.32.1 – 10.50.32.255 || Statische Adressen<br />
|-<br />
| || 10.50.33.0 – 10.50.34.255 || [[fff-nue2|fff-nue2-gw1]]<br />
|-<br />
| || 10.50.35.0 – 10.50.36.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey"> 10.50.37.0 – 10.50.37.255 </font> || --<br />
|-<br />
| || 10.50.38.0 – 10.50.39.254 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.40.0/21 || Nürnberg Hood ||<br />
|-<br />
| || 10.50.40.1 – 10.50.40.255 || Statische Adressen<br />
|-<br />
| || 10.50.41.0 – 10.50.42.255 || [[Server#FFF-GW-M1|FFF-GW-M1]]<br />
|-<br />
| || <font color="grey"> 10.50.43.0 - 10.50.43.255 </font> || <br />
|-<br />
| || 10.50.44.0 – 10.50.44.255 || (umgezogen) [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| ||10.50.45.0 – 10.50.46.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.47.0 – 10.50.47.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.48.0/21 || Ansbach Hood ||<br />
|-<br />
| || 10.50.48.1 – 10.50.48.255 || Statische Adressen<br />
|-<br />
| || 10.50.49.0 – 10.50.50.255 || <br />
|-<br />
| || 10.50.51.0 – 10.50.52.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.53.0 – 10.50.54.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| || <font color="grey">10.50.55.0 – 10.50.55.254</font> || <br />
|-<br />
! 10.50.56.0/22 || Hassberge Hood ||<br />
|-<br />
| || 10.50.56.1 – 10.50.56.255 || Statische Adressen<br />
|-<br />
| || 10.50.57.0 – 10.50.57.255 || [[Server#fff-has3|fff-has3]]<br />
|-<br />
| || 10.50.58.0 – 10.50.58.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.59.0 – 10.50.59.254 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
! 10.50.60.0/22 || HassbergeSued Hood ||<br />
|-<br />
| || 10.50.60.1 – 10.50.60.255 || Statische Adressen<br />
|-<br />
| || 10.50.61.0 – 10.50.61.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
| || 10.50.62.0 – 10.50.62.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.63.0 – 10.50.63.254 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
! 10.50.64.0/21 || Erlangen Hood ||<br />
|-<br />
| || 10.50.64.1 – 10.50.64.255 || Statische Adressen<br />
|-<br />
| || 10.50.65.0 – 10.50.66.255 || [[Server#fff-gw-kwadro|fff-gw-kwadro]]<br />
|-<br />
| || 10.50.67.0 – 10.50.68.255 || free<br />
|-<br />
| || 10.50.69.0 – 10.50.71.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.72.0/21 || Würzburg Hood ||<br />
|-<br />
| || 10.50.72.1 – 10.50.72.255 || Statische Adressen<br />
|-<br />
| || <font color="grey"> 10.50.73.0 – 10.50.74.255 </font>|| <br />
|-<br />
| || 10.50.75.0 – 10.50.76.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey"> 10.50.77.0 – 10.50.78.255 </font>|| <font color="grey"> (free) </font><br />
|-<br />
| || 10.50.79.0 – 10.50.79.254 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
! 10.50.80.0/21 || BGL ||<br />
|-<br />
| || 10.50.80.1 – 10.50.80.255 || Statische Adressen<br />
|-<br />
| || 10.50.81.0 – 10.50.82.255 || [[Server#watzmann|watzmann]]<br />
|-<br />
| || 10.50.83.0 – 10.50.84.255 || [[Server#staufen|staufen]]<br />
|-<br />
! 10.50.88.0/21 || NbgLand Hood ||<br />
|-<br />
| || 10.50.88.1 – 10.50.88.255 || Statische Adressen<br />
|-<br />
| || 10.50.89.0 – 10.50.89.255 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| || 10.50.90.0 - 10.50.91.255 || fff-gw-cdnbgland2 (Testbetrieb)<br />
|-<br />
| || <font color="grey">10.50.92.0 - 10.50.93.255</font> || <br />
|-<br />
| || 10.50.94.0 – 10.50.95.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.96.0/21 || Aschaffenburg Hood ||<br />
|-<br />
| || 10.50.96.1 – 10.50.96.255 || Statische Adressen<br />
|-<br />
| || 10.50.97.1 – 10.50.97.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
! 10.50.104.0/21 || Hof Hood ||<br />
|-<br />
| || 10.50.104.1 – 10.50.104.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.105.0 - 10.50.106.255</font> || free<br />
|-<br />
| || 10.50.107.0 – 10.50.107.255 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
| || 10.50.108.0 - 10.50.109.255 || fff-fr1-arm<br />
|-<br />
| || 10.50.110.1 - 10.50.111.254 || fff-gw-cdhof1<br />
|-<br />
! 10.50.112.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.112.1 – 10.50.119.254</font> || <br />
|-<br />
! 10.50.120.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.120.1 – 10.50.127.254</font> || <br />
|-<br />
! 10.50.128.0/24 || Test von Casandro ||<br />
|-<br />
| || 10.50.128.20 – 10.50.128.200 || 10.50.128.1<br />
|-<br />
! 10.50.129.0/24 || free ||<br />
|-<br />
| || 10.50.129.0 || free<br />
|-<br />
! 10.50.130.0/23 || Hardhöhe ||<br />
|-<br />
| || 10.50.130.1 - 10.50.130.255 || Statische Adressen<br />
|-<br />
| || 10.50.131.0 – 10.50.131.127 || Gateway Hochhaus<br />
|-<br />
! 10.50.132.0/22 || FabLabNbg Hood ||<br />
|-<br />
| || 10.50.132.1 - 10.50.132.255 || Statische Adressen<br />
|-<br />
| || 10.50.133.0 – 10.50.133.255 || FabLabNbgGW<br />
|-<br />
| || 10.50.134.0 - 10.50.135.254 || frei<br />
|-<br />
! 10.50.136.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.136.1 – 10.50.143.254</font> || <br />
|-<br />
! 10.50.144.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.144.1 – 10.50.159.254</font> || <br />
|-<br />
! 10.50.160.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.160.1 – 10.50.191.254</font> || <br />
|-<br />
! 10.50.192.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.192.1 – 10.50.223.254</font> || <br />
|-<br />
! 10.50.224.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.224.1 – 10.50.239.254</font> || <br />
|-<br />
! 10.50.240.0/21 || fffaux ||<br />
|-<br />
| || 10.50.240.1 – 10.50.240.255 || Statische Adressen<br />
|-<br />
| || 10.50.241.0 – 10.50.241.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.242.0 – 10.50.243.255 || [[Server#fff-fra1|fff-fra1]]<br />
|-<br />
| || 10.50.244.0 – 10.50.244.127 || Testinstallation Busch (Flo)<br />
|-<br />
| || <font color="grey"> 10.50.244.128 - 10.50.245.255 </font> || | <font color="grey"> (free) </font><br />
|-<br />
| || 10.50.246.0 - 10.50.247.254 || fff-gw-cdaux2<br />
|-<br />
<br />
! 10.50.248.0/22 || free ||<br />
|-<br />
| || 10.50.248.1 – 10.50.248.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.249.0 - 10.50.251.254</font> || <br />
|-<br />
! 10.50.252.0/22 || TUNNEL ||<br />
|-<br />
| || 10.50.252.0 fff_ro1 || 10.50.252.1 nue1 || <br />
|-<br />
| || 10.50.252.2 fff_ro1 || 10.50.252.3 watzmann || <br />
|-<br />
| || 10.50.252.4 fff_ro1 || 10.50.252.5 staufen || <br />
|-<br />
| || 10.50.252.6 fff_ro1 || 10.50.252.7 has2 || <br />
|-<br />
| || 10.50.252.8 fff_ro1 || 10.50.252.9 has || <br />
|-<br />
| || 10.50.252.10 ro1 || 10.50.252.11 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.12 fff-has2 || 10.50.252.13 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.14 fff-gw-m1 || 10.50.252.15 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || <font color="grey"> 10.50.252.16 (free) </font>|| 10.50.252.17 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || <font color="grey"> 10.50.252.18 (free)</font> || 10.50.252.19 nue1 ||<br />
|-<br />
| || 10.50.252.20 <font color="grey"> (free) </font> || 10.50.252.21 ro1 ||<br />
|-<br />
| || 10.50.252.22 fff-gw-yaga || 10.50.252.23 fff-wue1 ||<br />
|-<br />
| || 10.50.252.24 fff-gw-m1 || 10.50.252.25 fff-has2 ||<br />
|-<br />
| || 10.50.252.26 fff-gw-m1 || 10.50.252.27 fff-wue1 ||<br />
|-<br />
| || 10.50.252.28 fff-bbg || 10.50.252.29 fff-nue1 ||<br />
|-<br />
| || 10.50.252.30 fff-bbg || 10.50.252.31 fff-ro1 ||<br />
|-<br />
| || 10.50.252.32 fff-bbg || 10.50.252.33 fff-has2 ||<br />
|-<br />
| || 10.50.252.34 fff-bbg || <font color="grey"> 10.50.252.35 (free) </font> ||<br />
|-<br />
| || 10.50.252.36 fff-wue1 || 10.50.252.37 fff-bbg ||<br />
|-<br />
| || 10.50.252.38 fff-gw-m1 || 10.50.252.39 ro1 ||<br />
|-<br />
| || 10.50.252.40 fff-gw-yaga || 10.50.252.41 ro1 ||<br />
|-<br />
| || 10.50.252.42 fff-gw-yaga || 10.50.252.43 nue1 ||<br />
|-<br />
| || 10.50.252.44 fff-roffl || 10.50.252.45 fff-has2 ||<br />
|-<br />
| || 10.50.252.46 fff-fra1 || 10.50.252.47 fff-bbg ||<br />
|-<br />
| || <font color="grey"> 10.50.252.48 (free) </font>|| <font color="grey"> 10.50.252.49 (free) </font> ||<br />
|-<br />
| || 10.50.252.50 fff-roffl || 10.50.252.51 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.52 fff-has2 || 10.50.252.53 <font color="grey"> (free) </font> ||<br />
|-<br />
| || 10.50.252.54 fff-has2 || 10.50.252.55 fff-fra1 ||<br />
|-<br />
| || 10.50.252.56 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.57 kwadronaut ||<br />
|-<br />
| || 10.50.252.58 fff-gw-m1 || 10.50.252.59 kwadronaut ||<br />
|-<br />
| || 10.50.252.60 fff-nue1 || 10.50.252.61 kwadronaut ||<br />
|-<br />
| || 10.50.252.62 ro1 || 10.50.252.63 kwadronaut ||<br />
|-<br />
| || 10.50.252.64 staufen || 10.50.252.65 kwadronaut ||<br />
|-<br />
| || 10.50.252.66 watzmann || 10.50.252.67 kwadronaut ||<br />
|-<br />
| || 10.50.252.68 kwadronaut || 10.50.252.69 yaga ||<br />
|-<br />
| || 10.50.252.70 fff-has || 10.50.252.71 nue1 ||<br />
|-<br />
| || 10.50.252.72 fff-has || 10.50.252.73 fff-wue1 ||<br />
|-<br />
| || 10.50.252.74 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.75 fff-dns-cd1 ||<br />
|-<br />
| || 10.50.252.76 fff-has || 10.50.252.77 fff-has1 ||<br />
|-<br />
| || 10.50.252.78 fff-roffl || 10.50.252.79 fff-has1 ||<br />
|-<br />
| || 10.50.252.80 fff-has2 || 10.50.252.81 fff-has1 ||<br />
|-<br />
| || 10.50.252.82 fff-has || 10.50.252.83 fff-has3 ||<br />
|-<br />
| || 10.50.252.84 fff-has2 || 10.50.252.85 fff-has3 ||<br />
|-<br />
| || 10.50.252.86 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.87 fff-dns-cd2 ||<br />
|-<br />
| || 10.50.252.88 ro1 || 10.50.252.89 fablabnbggw ||<br />
|-<br />
| || 10.50.252.90 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.91 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.92 fff-has || 10.50.252.93 fff-has2 ||<br />
|-<br />
| || 10.50.252.94 ro1 || 10.50.252.95 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.96 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.97 fff-gw-cd2 ||<br />
|-<br />
| || 10.50.252.98 fff-gw-cd2 || 10.50.252.99 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.100 fff-gw-cd2 || 10.50.252.101 has2 ||<br />
|-<br />
| || 10.50.252.102 fff-gw-cd2 || 10.50.252.103 fff-gw-m1 ||<br />
|-<br />
| || 10.50.252.104 fff-gw-cd2 || 10.50.252.105 fff-dns-cd1 ||<br />
|-<br />
| || 10.50.252.106 fff-fr1-arm || 10.50.252.107 ro1 ||<br />
|-<br />
| || 10.50.252.250 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.251 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.252 Testsystem von [[Benutzer:ChristianD]] || 10.50.252.253 Testsystem2 von [[Benutzer:ChristianD]] ||<br />
|-<br />
|}<br />
<br />
=== 10.83.0.0/16 ===<br />
<br />
{|<br />
! !! Bereich !! Bereitgestellt durch<br />
|-<br />
! 10.83.0.0/16 || decentraliced keyXchange network ||<br />
|-<br />
| || <font color="grey">10.83.0.1 - 10.83.255.254</font> || <br />
|-<br />
! 10.83.0.0/22 || Trainstation ||<br />
|-<br />
| || 10.83.0.1 - 10.83.0.64 || static<br />
|-<br />
| || 10.83.1.0 - 10.83.2.0 || fff-nue2-gw2.fff.community<br />
|-<br />
! 10.83.4.0/22 || Nuremberg ||<br />
|-<br />
! 10.83.8.0/22 || Furth ||<br />
|-<br />
| || 10.83.8.1 || fff-gw-cd1.fff.community<br />
|-<br />
| || 10.83.9.0 - 10.83.9.255 || DHCP fff-gw-cd1.fff.community<br />
|-<br />
! 10.83.252.0/22 || Master IPs || for use as /32 routed IPs withing L3 network<br />
|-<br />
| || 10.83.252.1/32 || fff-nue2-gw2.gw.fff.community ||<br />
|-<br />
| || 10.83.252.2/32 || fff-nue2-gw1.gw.fff.community ||<br />
|-<br />
| || 10.83.252.3/32 || fff-gw-cd1.gw.fff.community ||<br />
|-<br />
| || 10.83.252.4/32 || fff-gw-m2.gw.fff.community ||<br />
|-<br />
|}<br />
<br />
== Statische IP-Adressen ==<br />
Dienste müssen Ihre IP-Adressen natürlich aus dem Subnetz beziehen, in welchem sie angeschlossen sind. Damit es keine Konflikte gibt, muss die IP-Adresse hier registriert werden.<br />
<br />
=== Default Hood ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.16.0 – 10.50.17.255 || || IP-Bereich Default Hood || <br />
|-<br />
| 10.50.16.2 || fff-nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.16.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.16.11 || c.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.21 || rns3.franken.ff || DNS PoC - Recursor #3 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.16.100 || netmon.freifunk-franken.de || || [[Server#si1|Details]]<br />
|-<br />
| 10.50.16.112 ||???.franken.ff || Raspberry Pi, Test owncloud, FTP || MartinS<br />
|-<br />
| 10.50.16.128 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.150 ||Diagnose ChristianD || Diagnose ChristianD || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.16.200 ||???.franken.ff || Fileserver || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.16.212 ||???.franken.ff || NAS, verschiedene Services || JomJom<br />
|-<br />
| 10.50.16.222 ||???.franken.ff || VM, mom. nur Test || pixelchrome<br />
|-<br />
| 10.50.17.112 ||???.franken.ff || Webserver, Tests || wolli112<br />
|}<br />
<br />
=== Hood Fürth ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.32.0 – 10.50.32.255 || || IP-Bereich Fürth Hood || <br />
|-<br />
| 10.50.32.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.32.3 || fff-uk1.freifunk-franken.de || || [[Server#fff-uk1|Details]]<br />
|-<br />
| 10.50.32.4 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|- <br />
| 10.50.32.5 || [[fff-nue2|fff-nue2-gw1]] || Gateway || [[Benutzer:RedDog|RedDog]] [[Benutzer:Mayosemmel|Mayosemmel]] [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.6 || frei || ||<br />
|- <br />
| <font color="grey"> 10.50.32.7 </font>||<font color="grey"> (frei) </font> || ||<br />
|-<br />
| 10.50.32.26 || Test-PI || Statische IP des RasPI für Testzwecke || [[Benutzer:Hobo|Hobo]] <br />
|-<br />
| 10.50.32.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.32.70 || NAT für priv. Netz || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.71 || testbridgeclient.bridge.fff.community || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.100 || MicroNAS || anonymous FTP (10GB) || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.101 || Wetterstation || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Daten bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.102 || Wetterkamera || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Bilder bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.108 || williams || privater PC || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.109 || Raspi || Raspi Server im Höffner || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.110 || - || - || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.111 || stmichael.bridge.ws13.fff.community || Nanobeam M5 Bridge als AP auf St. Michael Richtung DelphiN || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.112 || ws13.bridge.stmichael.fff.community || Nanobeam M5 Bridge als Client bei DelphiN. Richtung St. Michael || [[Benutzer:delphiN|delphiN]], [[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.113 || stmichael.bridge.hoeffner.fff.community || Bridge als AP auf St. Michael. Richtung Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.114 || hoeffner.bridge.stmichael.fff.community || Bridge als Client bei Hoeffner. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.115 || clockwork.bridge.stmichael.fff.community || Bridge als Client bei Clockwork. Richtung St. Michael || [[Benutzer:clockwork|clockwork]],[[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]], <br />
|-<br />
| 10.50.32.117 || || ToughSwitch Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.118 || || ToughSwitch auf WS13 || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.119 || || ToughSwitch auf StMichael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.120 || || ToughSwitch im Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.121 || || Bridge als AP auf St. Michael. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.122 || || Bridge als Client in Europaallee. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.123 || || Reserviert: Bridge als AP auf Hardhöhe. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.124 || || Bridge als Client in Europaallee. Richtung Hardhöhe || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.150 || ChristianD's PC || FFF-Netz ohne Internet || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.151 || feste Laptop IP || Für Speedtests mit manuellen Gateway || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.152 || RasPi || Testsystem || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.170 || HoeffnerPrinter || Drucker Computerraum Höffner || [[Benutzer:delphiN|delphiN]] <br />
|-<br />
| 10.50.32.199 || || Ralphs home-server ftp/http || [[Benutzer:dk5ras|dk5ras]] <br />
|}<br />
<br />
=== Hood Nürnberg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.40.0 – 10.50.40.255 || || IP-Bereich Nürnberg Hood || <br />
|-<br />
|<strike>10.50.40.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.40.6 || fff-bbg-tmp|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.7 || fff-gw-yaga|| || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.40.8 || fff-bbg|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.10 || FFF-GW-M1 || || [[Server#FFF-GW-M1|Details]]<br />
|-<br />
| 10.50.40.11 || a.ns.franken.ff || DNS PoC - Master || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.12 || b.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.20 || - – - || Direct Connect HUB || [[Benutzer:TheFroggy|TheFroggy]]<br />
|-<br />
| 10.50.40.21 || rns1.franken.ff || DNS PoC - Recursor #1 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.22 || rns2.franken.ff || DNS PoC - Recursor #2 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| <strike>10.50.40.40</strike> || <strike>fff-synology.freifunk-franken.de</strike> || Umgezogen nach NBGLand || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.40.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.40.51 || mayo-test.fff.community || || [[Benutzer:mayosemmel|mayosemmel]]<br />
|-<br />
| 10.50.40.52 || VPN ins FF || || [[Benutzer:mayosemmel|mayosemmel]]<br />
|-<br />
| 10.50.40.66 || flightradar.freifunk-franken.de || Dump1090 || [[Benutzer:Sixkiller6kl|sixkiller6kl]]<br />
|-<br />
| 10.50.40.88 || Knotenpunkt || Test-Server || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.98 || jabber.pm-ib.de || Jabber-Server || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.99 || K4CG || Dinge-Tester || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.100 || K4CG || Dinge-Tester || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.101 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.102 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.103 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.110 || ff_br_Spenglerstr || 5-GHz-Bridge Spenglerstr --> Johannis || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.111 || ff_Johannis || 5-GHz-Bridge Johannis --> Spenglerstr || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.120 || -- || 5-GHz-Access Point (Schniegling) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.121 || -- || 5-GHz-Client (Naturfreundehaus Nürnberg Mitte) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.122 || -- || 5-GHz-Client (Quelle GU) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.123 || -- || 5-GHz-AccessPoint (Quelle, Internetanbindung) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.130 || ff_nhgbr_Johnny || 5-GHz-Master (Standort Spenglerstr) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.131 || ff_nhgbr_NHG || 5-GHz-Slave (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.132 || ff_NHG_Osten || 5-GHz-Master (Standort Nachbarschaftshaus Goho, Richtung Osten) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.135 || ff_nhgswitch_NHG || POE-Switch (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.140 || ff_TS_PoE_tmp || 5-Port POE-Switch (für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.141 || ff_NS_M5_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.142 || ff_NS_M5_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.143 || ff_PB_5AC_500_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.144 || ff_PB_5AC_500_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.145 || ff_nhgbrsüd_M5loco_Master || 5-GHz-Master (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.146 || ff_Bauerngassebr_M5loco_Slave || 5-GHz-Slave (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.200 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Client, Routerfernwartung || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.206 || --- || lokale Dienste || [[Benutzer:meskal|meskal]]<br />
|-<br />
| 10.50.40.201 – 10.50.40.205|| Test || bitte vorläufig freihalten, danke || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.230 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.231 ||???.franken.ff || Juniper SRX (VRF) || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.232 ||???.franken.ff || Raspberry Pi || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.233 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.234 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
| 10.50.43.165 || fffsvr01.franken.freifunk.net || SMB, FTP Server 250GB || [[Benutzer:ManuelS|ManuelS]]<br />
|}<br />
<br />
=== Hood Ansbach ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.48.0 – 10.50.48.255 || || IP-Bereich Ansbach Hood || <br />
|-<br />
| 10.50.48.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.48.3 || fff-gw-cdfue1 || || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| 10.50.48.20 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.21 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.48.230 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.231 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.232 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.233 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.234 || || mom. nur Test || JuzeCr<br />
|}<br />
<br />
=== Hood Hassberge ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.56.0 – 10.50.56.255 || || IP-Bereich Hassberge Hood || <br />
|-<br />
| 10.50.56.1 || fff-has1|| || [[Server#fff-has1|Details]] <br />
|-<br />
| 10.50.56.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]] <br />
|-<br />
| 10.50.56.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.56.7 || fff-roffl|| || [[Server#fff-roffl|Details]]<br />
|-<br />
| 10.50.56.8 || fff-has3 || || [[Server#fff-has3|Details]] <br />
|-<br />
| 10.50.56.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.56.100 || ff_MT_RB260GSP_PoE_Ost || 5-Port POE-Switch (Ostheim-Hofheim) || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.101 || ff_NS_M5_Master_Ostheim_Hofheim || 5-GHz-Master (Richtfunkstrecke von Ostheim nach Hofheim) || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.40.102 || ff_NS_M5_Slave_Hofheim_Ostheim || 5-GHz-Slave (Richtfunkstrecke von Ostheim nach Hofheim) || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.103 || ff_MT_RB260GSP_PoE_Hoh || 5-Port POE-Switch (Hofheim-Ostheim) || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| Bitte den Bereich 10.50.56.120 – 10.50.56.129 für [[Benutzer:Plocker|Plocker]] frei lassen<br />
|-<br />
| 10.50.56.123 || Teeworlds-Game-Server || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.124 || OwnCloud + Wiki || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.125 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.126 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.132 ||<strike> Webserver + MUD? || || [[Benutzer:PeterPhilipp|area52]]</strike><br />
|}<br />
<br />
=== Hood Hassberge Süd ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.60.0 – 10.50.60.255 || || IP-Bereich HassbergeSued Hood ||<br />
|-<br />
|<strike> 10.50.60.1</strike> || <strike>fff-has1 </strike>|| || [[Server#fff-has1|Details]]<br />
|-<br />
| 10.50.60.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.60.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.60.7 || fff-roffl|| || [[Server#fff-roffl|Details]] <br />
|-<br />
| 10.50.60.10 || Webcam Meehäusle Parkplatz|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.11 || Webcam Meehäusle Biergarten|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.100 /mediawiki || Webserver Mediawiki (in progress: Wikipedia(de)offline mirror)|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.101 /wiki || Raspi Webserver mit MediaWiki (Haßberge Wiki)|| || [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Erlangen ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.64.0 – 10.50.64.255 || || IP-Bereich Erlangen Hood || <br />
|-<br />
| 10.50.64.3 || fff-gw-yaga || || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.64.4 || fff-gw-kwadro || || [[Server#fff-gw-kwadro|Details]]<br />
|-<br />
| 10.50.64.10 || radiator.franken.ff || || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.11 || voip-1.radiator.franken.ff || Outernet, VoIP mittels SIP || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.12 || cam-1.radiator.franken.ff || IP-Cam || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.20 || radiatrix.franken.ff || geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.21 || cam-1.radiatrix.franken.ff || IP-Cam, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.22 || voip-1.radiatrix.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.30 || long.franken.ff || geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.31 || cam-1.long.franken.ff || IP-Cam || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.33 || voip-1.long.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.40 |||| Streaming Erlangen (im Aufbau) || [[Benutzer:R.funkt|R.funkt]]<br />
|-<br />
| 10.50.64.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.64.60 || gate3 || Dev || [[Benutzer:Jonas-bebe|Jonas-bebe]]<br />
|-<br />
| 10.50.64.70 |||| Raspi-Test || [[Benutzer:Dieter123|Dieter123]]<br />
|-<br />
| 10.50.64.78 |||| IP-CAM || [[Benutzer:moonrat|moonrat]]<br />
|-<br />
| 10.50.64.79 |||| IP-CAM || [[Benutzer:moonrat|moonrat]]<br />
|}<br />
<br />
=== Hood Würzburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.72.0 – 10.50.79.255 || || IP-Bereich Würzburg Hood || <br />
|-<br />
| 10.50.72.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.72.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.72.6 || fff-wue1|| || [[Server#fff-wue1|Details]] <br />
|-<br />
| <font color="grey"> 10.50.72.7 </font>||<font color="grey"> (frei) </font> <br />
|-<br />
| 10.50.72.9 || Raspi-test|| || [[MisterCrumble|MisterCrumble]]<br />
|-<br />
| 10.50.72.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.72.72 || WikipediaClon || Soll ein Clon der Wikipedia werden. || [[Benutzer:Luensche|Luensche]]<br />
|-<br />
| 10.50.72.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood BGL ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.80.0 – 10.50.87.255 || || IP-Bereich BGL Hood || <br />
|-<br />
| 10.50.80.1 || watzmann || ||<br />
|-<br />
| 10.50.80.2 || staufen || ||<br />
|}<br />
<br />
=== Hood Nürnberger-Land ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.88.0 – 10.50.95.255 || || IP-Bereich NbgLand Hood || <br />
|-<br />
| 10.50.88.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.88.10 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.11 || fff-gw-cdnbgland2 || Gateway (Testbetrieb) || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.40 || fff-synology.freifunk-franken.de || Umzug nach Hood-Teilung || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.88.170 ||???.franken.ff || 5-GHz Richtfunk AP || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.171 ||???.franken.ff || 5-GHz Richtfunk Client || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.172 ||???.franken.ff || VM zum Testen || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood Aschaffenburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.96.0 – 10.50.103.255 || || IP-Bereich Aschaffenburg || <br />
|-<br />
| 10.50.96.x || fff-res|| || <br />
|-<br />
| 10.50.96.3 || fff-has || Gateway [[Server#fff-has|Details]]<br />
|| [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Hof ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.104.0 – 10.50.111.255 || || IP-Bereich Hof || <br />
|-<br />
| 10.50.104.1 || fff-has1 || Gateway [[Server#fff-has1|Details]]<br />
|| [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.104.2 || fff-fr1-arm || Gateway || [[User:RedDog]]<br />
|-<br />
| 10.50.104.10 || fff-gw-cdhof1 || Gateway || ChristianD<br />
|}<br />
<br />
=== Hood FabLabnbg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.132.0 – 10.50.134.255 || || IP-Bereich FabLabnbg || <br />
|-<br />
| 10.50.132.1 || fablab || Gateway FabLabnbg || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|-<br />
| 10.50.132.2 || Switch || Switch || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|-<br />
| 10.50.132.9 || Raspberry Pi || Für Alfredmaster || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.132.10 || 5GHz Test || 5GHz Test || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|}<br />
<br />
=== Hood Hardhöhe ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.130.0 – 10.50.131.255 || || IP-Bereich Hardhöhe || <br />
|-<br />
| 10.50.130.1 || fff-gw-db0fue1 || Gateway Hardhöhedach || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.11 || fff-5gs1-hhd || erste LBE-5AC-16-120 || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.12 || fff-5gs2-hhd || zweite LBE-5AC-16-120 || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|}<br />
<br />
=== Hood Aux ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
!10.50.240.1 – 10.50.247.254 || || IP-Bereich aux Hood || <br />
|-<br />
| 10.50.240.1 || fff-bbg || ||<br />
|-<br />
| 10.50.240.2 || fff-fra1 || ||<br />
|-<br />
| 10.50.240.3 || fff-gw-cdaux2 || ||<br />
|-<br />
| 10.50.240.20 || || Testgateway Flo für Hotel Busch |||<br />
|-<br />
| 10.50.240.11 || AP.bridge1.hoeffner.fff.community || Bridge AP Höffner || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.12 || S01.bridge1.hoeffner.fff.community || Bridge Station Hardhöhe || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.100 || fff-client-auxcd1 || Client zur Fernwartung aux || [[Benutzer:ChristianD|ChristianD]] ||<br />
|}<br />
<br />
= BSSID =<br />
<br />
{|<br />
! BSSID !! Hood !!<br />
|-<br />
| 00:ca:ff:ee:ba:be || legacy ||<br />
|-<br />
| ca:ff:ee:ba:be:00 || Trainstation ||<br />
|-<br />
| ca:ff:ee:ba:be:02 || Fürth || <br />
|-<br />
| ca:ff:ee:ba:be:03 || Nürnberg ||<br />
|-<br />
| ca:ff:ee:ba:be:04 || FabLabNbg ||<br />
|-<br />
| ca:ff:ee:ba:be:05 || Hardhöhe ||<br />
|}</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Portal:Netz&diff=6623
Portal:Netz
2016-05-19T17:13:04Z
<p>Green: /* 10.50.0.0/16 */</p>
<hr />
<div>== Das Netz ==<br />
Eine Karte der aktiven Router gibt es [https://monitoring.freifunk-franken.de/map].<br />
<br />
Eine Karte der Hoods ist [http://keyserver.freifunk-franken.de/fff/voronoimap.php hier] zu finden.<br />
<br />
Die [https://monitoring.freifunk-franken.de/routers Liste der Router] kann dank Monitoring immer live verfolgt werden. Infos über die Schreibweise (z.B. "/20") gibt es in der [http://de.wikipedia.org/wiki/CIDR Wikipedia].<br />
<br />
=== Gateway ===<br />
Erste Versuche einer sinnvollen Aufteilung von Gateways. Erweiterungen und Verbesserungen sind jederzeit erwünscht. [https://pad.freifunk.net/p/Gatewayaufteilung-Franken Zum Pad]<br />
<br />
== IP-Netz ==<br />
Mit der Netz-Umstellung vom 22.03.2014 haben wir nicht mehr länger ein großes [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_2_.E2.80.93_Sicherungsschicht_.28Data_Link_Layer.29 Layer-II-Netz], welches durch das [https://de.wikipedia.org/wiki/B.A.T.M.A.N. B.A.T.M.A.N. advanced]-Protokoll geroutet wird. Seitdem gibt es mehrere [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_3_.E2.80.93_Vermittlungsschicht_.28Network_Layer.29 Layer-III-Netze] (Hoods). Ein Layer-III-Netz entsteht grundsätzlich, indem hier ein Subnetz eingetragen wird. Wie dabei genau vorgegangen wird, steht in [[HoodVerwaltung]].<br />
Für jedes Subnetz muss separat abgewogen werden, wie groß es werden wird und wo es dann in die bestehenden Subnetze am besten eingegliedert werden kann.<br />
<br />
==== DHCP ====<br />
[[Datei:Hoods.png|200px|thumb|right|Vorschlag für die Hood-Organisation]]<br />
Damit simple Clients das neue Subnetz nutzen können, muss ein eigener DHCP-Server pro Subnetz bereit gestellt werden. Es macht dabei häufig Sinn, das Subnetz in IP-Bereiche aufzuteilen, die von mehreren DHCP-Servern verteilt werden. Ein zweiter DHCP-Server ermöglicht zum einen eine Lastverteilung, zum anderen erhöht sich die Ausfallsicherheit. Der DHCP-Server muss den Clients ein Default-Gateway und mindestens einen DNS-Server zuweisen. Da das Default-Gateway ebenfalls innerhalb des Subnetzes liegen muss, bietet es sich an, den selben Server, auf dem das DHCP läuft, zu nutzen.<br />
<br />
==== OLSR-Router ====<br />
Das Subnetz muss anschließend an das vorhandene Freifunknetz angeschlossen werden. Dazu muss eine Verbindung zu einem bestehenden OLSR-Router aufgebaut werden. Dies kann eine VPN-Verbindung, aber auch eine Wifi-Verbindung sein und muss individuell zwischen den zwei Parteien ausgehandelt werden. Es kann sinnvoll sein, Verbindungen zu mehr als einem OLSR-Router zu haben. Sobald der eigene Router an das OLSR-Netz angebunden ist, ist er selbst ein OLSR-Router.<br />
<br />
An den eigenen OLSR-Router können nun Accesspoints angeschlossen werden. Dies kann per VPN, WLAN, Kabel oder anderweitig geschehen. Es ist auch möglich, den Accesspoint selbst als OLSR-Router anzubinden. Auch diese Konfiguration ist individuell zu klären. Ein Accesspoint kann ein (oder mehrere) einfacher Wifi-AP oder auch ein Array von mehreren B.A.T.M.A.N.-Knoten sein. Es sollte vermieden werden, dass sich Subnetze vermischen. Dies würde immer dann passieren, wenn zwei Layer-II-Netze, die eigentlich unterschiedliche Subnetze verteilen, verbunden werden. Besonders beim B.A.T.M.A.N.-Protokoll besteht hier leicht diese Gefahr; daher sollte für jedes Subnetz eine eigene BSSID und ESSID gewählt werden.<br />
<br />
==== Aus Routersicht ====<br />
Nur Router in einer Hood können sich per B.A.T.M.A.N. advanced vermaschen, sowohl per VPN, also auch per WLAN. Daher müssen Router die räumlich nahe beieinander stehen auch in derselben Hood sein. Durch das Vermaschen des Netzes wird allerdings auch Verwaltungs-Verkehr erzeugt (Overhead). Je größer die Hood, desto größer der Overhead.<br />
<br />
Eine Verbindung zwischen Routern in unterschiedlichen Hoods ist per IP (OSI Schicht 3) möglich.<br />
<br />
Wenn im Netmon kein Standort eingegeben wurde, dann landet der Router in der Dafault-Hood.<br />
<br />
==== Monitoring (Netmon) ====<br />
Aktuell können sich Knoten nur über ein IPv6-Link-Local-Interface beim Netmon anmelden und Netmon kann die Knoten nur über eine IPv6-Link-Local-Adresse abfragen. Hier muss ein neuer Mechanismus gefunden werden, der es ermöglicht, die Knoten über Subnetze hinweg anzusprechen.<br />
<br />
Als Workaround ist es möglich, über einen Layer-II-Tunnel zum Netmon-Server das Subnetz an das Netmon anzubinden. Auf dem Netmon-Server werden alle Subnetze in einem Bridge-Interface zusammengefasst, welches keine Pakete weiterleiten kann.<br />
<br />
==== Wireless-LAN ====<br />
Wir haben uns auf folgende WLAN-Parameter verständigt:<br />
'''ESSID: franken.freifunk.net'''. Kanal 1.<br />
<br />
== Liste der Subnetze ==<br />
<br />
=== 10.50.0.0/16 ===<br />
<br />
{|<br />
! !! Bereich !! Bereitgestellt durch<br />
|-<br />
! 10.50.0.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.0.1 – 10.50.15.254</font> || <br />
|-<br />
! 10.50.16.0/20 || Default Hood ||<br />
|-<br />
| || 10.50.16.1 – 10.50.17.255 || Statische Adressen<br />
|-<br />
| || 10.50.18.0 – 10.50.19.255 || --<br />
|-<br />
| || 10.50.20.0 – 10.50.21.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey">10.50.22.0 – 10.50.23.254 </font> || <br />
|-<br />
| || <font color="grey">10.50.24.0 – 10.50.31.254 </font> || <br />
|-<br />
! 10.50.32.0/21 || Fürth Hood ||<br />
|-<br />
| || 10.50.32.1 – 10.50.32.255 || Statische Adressen<br />
|-<br />
| || 10.50.33.0 – 10.50.34.255 || [[fff-nue2|fff-nue2-gw1]]<br />
|-<br />
| || 10.50.35.0 – 10.50.36.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey"> 10.50.37.0 – 10.50.37.255 </font> || --<br />
|-<br />
| || 10.50.38.0 – 10.50.39.254 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.40.0/21 || Nürnberg Hood ||<br />
|-<br />
| || 10.50.40.1 – 10.50.40.255 || Statische Adressen<br />
|-<br />
| || 10.50.41.0 – 10.50.42.255 || [[Server#FFF-GW-M1|FFF-GW-M1]]<br />
|-<br />
| || <font color="grey"> 10.50.43.0 - 10.50.43.255 </font> || <br />
|-<br />
| || 10.50.44.0 – 10.50.44.255 || (umgezogen) [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| ||10.50.45.0 – 10.50.46.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.47.0 – 10.50.47.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.48.0/21 || Ansbach Hood ||<br />
|-<br />
| || 10.50.48.1 – 10.50.48.255 || Statische Adressen<br />
|-<br />
| || 10.50.49.0 – 10.50.50.255 || <br />
|-<br />
| || 10.50.51.0 – 10.50.52.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.53.0 – 10.50.54.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| || <font color="grey">10.50.55.0 – 10.50.55.254</font> || <br />
|-<br />
! 10.50.56.0/22 || Hassberge Hood ||<br />
|-<br />
| || 10.50.56.1 – 10.50.56.255 || Statische Adressen<br />
|-<br />
| || 10.50.57.0 – 10.50.57.255 || [[Server#fff-has3|fff-has3]]<br />
|-<br />
| || 10.50.58.0 – 10.50.58.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.59.0 – 10.50.59.254 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
! 10.50.60.0/22 || HassbergeSued Hood ||<br />
|-<br />
| || 10.50.60.1 – 10.50.60.255 || Statische Adressen<br />
|-<br />
| || 10.50.61.0 – 10.50.61.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
| || 10.50.62.0 – 10.50.62.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.63.0 – 10.50.63.254 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
! 10.50.64.0/21 || Erlangen Hood ||<br />
|-<br />
| || 10.50.64.1 – 10.50.64.255 || Statische Adressen<br />
|-<br />
| || 10.50.65.0 – 10.50.66.255 || [[Server#fff-gw-kwadro|fff-gw-kwadro]]<br />
|-<br />
| || 10.50.67.0 – 10.50.68.255 || free<br />
|-<br />
| || 10.50.69.0 – 10.50.71.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.72.0/21 || Würzburg Hood ||<br />
|-<br />
| || 10.50.72.1 – 10.50.72.255 || Statische Adressen<br />
|-<br />
| || <font color="grey"> 10.50.73.0 – 10.50.74.255 </font>|| <br />
|-<br />
| || 10.50.75.0 – 10.50.76.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey"> 10.50.77.0 – 10.50.78.255 </font>|| <font color="grey"> (free) </font><br />
|-<br />
| || 10.50.79.0 – 10.50.79.254 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
! 10.50.80.0/21 || BGL ||<br />
|-<br />
| || 10.50.80.1 – 10.50.80.255 || Statische Adressen<br />
|-<br />
| || 10.50.81.0 – 10.50.82.255 || [[Server#watzmann|watzmann]]<br />
|-<br />
| || 10.50.83.0 – 10.50.84.255 || [[Server#staufen|staufen]]<br />
|-<br />
! 10.50.88.0/21 || NbgLand Hood ||<br />
|-<br />
| || 10.50.88.1 – 10.50.88.255 || Statische Adressen<br />
|-<br />
| || 10.50.89.0 – 10.50.89.255 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| || 10.50.90.0 - 10.50.91.255 || fff-gw-cdnbgland2 (Testbetrieb)<br />
|-<br />
| || <font color="grey">10.50.92.0 - 10.50.93.255</font> || <br />
|-<br />
| || 10.50.94.0 – 10.50.95.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.96.0/21 || Aschaffenburg Hood ||<br />
|-<br />
| || 10.50.96.1 – 10.50.96.255 || Statische Adressen<br />
|-<br />
| || 10.50.97.1 – 10.50.97.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
! 10.50.104.0/21 || Hof Hood ||<br />
|-<br />
| || 10.50.104.1 – 10.50.104.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.105.0 - 10.50.106.255</font> || free<br />
|-<br />
| || 10.50.107.0 – 10.50.107.255 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
| || 10.50.108.0 - 10.50.109.255 || fff-fr1-arm<br />
|-<br />
| || 10.50.110.1 - 10.50.111.254 || fff-gw-cdhof1<br />
|-<br />
! 10.50.112.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.112.1 – 10.50.119.254</font> || <br />
|-<br />
! 10.50.120.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.120.1 – 10.50.127.254</font> || <br />
|-<br />
! 10.50.128.0/24 || Test von Casandro ||<br />
|-<br />
| || 10.50.128.20 – 10.50.128.200 || 10.50.128.1<br />
|-<br />
! 10.50.129.0/24 || free ||<br />
|-<br />
| || 10.50.129.0 || free<br />
|-<br />
! 10.50.130.0/23 || Hardhöhe ||<br />
|-<br />
| || 10.50.130.1 - 10.50.130.255 || Statische Adressen<br />
|-<br />
| || 10.50.131.0 – 10.50.131.127 || Gateway Hochhaus<br />
|-<br />
! 10.50.132.0/22 || FabLabNbg Hood ||<br />
|-<br />
| || 10.50.132.1 - 10.50.132.255 || Statische Adressen<br />
|-<br />
| || 10.50.133.0 – 10.50.133.255 || FabLabNbgGW<br />
|-<br />
| || 10.50.134.0 - 10.50.135.254 || frei<br />
|-<br />
! 10.50.136.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.136.1 – 10.50.143.254</font> || <br />
|-<br />
! 10.50.144.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.144.1 – 10.50.159.254</font> || <br />
|-<br />
! 10.50.160.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.160.1 – 10.50.191.254</font> || <br />
|-<br />
! 10.50.192.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.192.1 – 10.50.223.254</font> || <br />
|-<br />
! 10.50.224.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.224.1 – 10.50.239.254</font> || <br />
|-<br />
! 10.50.240.0/21 || fffaux ||<br />
|-<br />
| || 10.50.240.1 – 10.50.240.255 || Statische Adressen<br />
|-<br />
| || 10.50.241.0 – 10.50.241.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.242.0 – 10.50.243.255 || [[Server#fff-fra1|fff-fra1]]<br />
|-<br />
| || 10.50.244.0 – 10.50.244.127 || Testinstallation Busch (Flo)<br />
|-<br />
| || <font color="grey"> 10.50.244.128 - 10.50.245.255 </font> || | <font color="grey"> (free) </font><br />
|-<br />
| || 10.50.246.0 - 10.50.247.254 || fff-gw-cdaux2<br />
|-<br />
<br />
! 10.50.248.0/22 || free ||<br />
|-<br />
| || 10.50.248.1 – 10.50.248.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.249.0 - 10.50.251.254</font> || <br />
|-<br />
! 10.50.252.0/22 || TUNNEL ||<br />
|-<br />
| || 10.50.252.0 fff_ro1 || 10.50.252.1 nue1 || <br />
|-<br />
| || 10.50.252.2 fff_ro1 || 10.50.252.3 watzmann || <br />
|-<br />
| || 10.50.252.4 fff_ro1 || 10.50.252.5 staufen || <br />
|-<br />
| || 10.50.252.6 fff_ro1 || 10.50.252.7 has2 || <br />
|-<br />
| || 10.50.252.8 fff_ro1 || 10.50.252.9 has || <br />
|-<br />
| || 10.50.252.10 ro1 || 10.50.252.11 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.12 fff-has2 || 10.50.252.13 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.14 fff-gw-m1 || 10.50.252.15 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || <font color="grey"> 10.50.252.16 (free) </font>|| 10.50.252.17 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || <font color="grey"> 10.50.252.18 (free)</font> || 10.50.252.19 nue1 ||<br />
|-<br />
| || 10.50.252.20 <font color="grey"> (free) </font> || 10.50.252.21 ro1 ||<br />
|-<br />
| || 10.50.252.22 fff-gw-yaga || 10.50.252.23 fff-wue1 ||<br />
|-<br />
| || 10.50.252.24 fff-gw-m1 || 10.50.252.25 fff-has2 ||<br />
|-<br />
| || 10.50.252.26 fff-gw-m1 || 10.50.252.27 fff-wue1 ||<br />
|-<br />
| || 10.50.252.28 fff-bbg || 10.50.252.29 fff-nue1 ||<br />
|-<br />
| || 10.50.252.30 fff-bbg || 10.50.252.31 fff-ro1 ||<br />
|-<br />
| || 10.50.252.32 fff-bbg || 10.50.252.33 fff-has2 ||<br />
|-<br />
| || 10.50.252.34 fff-bbg || <font color="grey"> 10.50.252.35 (free) </font> ||<br />
|-<br />
| || 10.50.252.36 fff-wue1 || 10.50.252.37 fff-bbg ||<br />
|-<br />
| || 10.50.252.38 fff-gw-m1 || 10.50.252.39 ro1 ||<br />
|-<br />
| || 10.50.252.40 fff-gw-yaga || 10.50.252.41 ro1 ||<br />
|-<br />
| || 10.50.252.42 fff-gw-yaga || 10.50.252.43 nue1 ||<br />
|-<br />
| || 10.50.252.44 fff-roffl || 10.50.252.45 fff-has2 ||<br />
|-<br />
| || 10.50.252.46 fff-fra1 || 10.50.252.47 fff-bbg ||<br />
|-<br />
| || <font color="grey"> 10.50.252.48 (free) </font>|| <font color="grey"> 10.50.252.49 (free) </font> ||<br />
|-<br />
| || 10.50.252.50 fff-roffl || 10.50.252.51 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.52 fff-has2 || 10.50.252.53 <font color="grey"> (free) </font> ||<br />
|-<br />
| || 10.50.252.54 fff-has2 || 10.50.252.55 fff-fra1 ||<br />
|-<br />
| || 10.50.252.56 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.57 kwadronaut ||<br />
|-<br />
| || 10.50.252.58 fff-gw-m1 || 10.50.252.59 kwadronaut ||<br />
|-<br />
| || 10.50.252.60 fff-nue1 || 10.50.252.61 kwadronaut ||<br />
|-<br />
| || 10.50.252.62 ro1 || 10.50.252.63 kwadronaut ||<br />
|-<br />
| || 10.50.252.64 staufen || 10.50.252.65 kwadronaut ||<br />
|-<br />
| || 10.50.252.66 watzmann || 10.50.252.67 kwadronaut ||<br />
|-<br />
| || 10.50.252.68 kwadronaut || 10.50.252.69 yaga ||<br />
|-<br />
| || 10.50.252.70 fff-has || 10.50.252.71 nue1 ||<br />
|-<br />
| || 10.50.252.72 fff-has || 10.50.252.73 fff-wue1 ||<br />
|-<br />
| || 10.50.252.74 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.75 fff-dns-cd1 ||<br />
|-<br />
| || 10.50.252.76 fff-has || 10.50.252.77 fff-has1 ||<br />
|-<br />
| || 10.50.252.78 fff-roffl || 10.50.252.79 fff-has1 ||<br />
|-<br />
| || 10.50.252.80 fff-has2 || 10.50.252.81 fff-has1 ||<br />
|-<br />
| || 10.50.252.82 fff-has || 10.50.252.83 fff-has3 ||<br />
|-<br />
| || 10.50.252.84 fff-has2 || 10.50.252.85 fff-has3 ||<br />
|-<br />
| || 10.50.252.86 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.87 fff-dns-cd2 ||<br />
|-<br />
| || 10.50.252.88 ro1 || 10.50.252.89 fablabnbggw ||<br />
|-<br />
| || 10.50.252.90 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.91 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.92 fff-has || 10.50.252.93 fff-has2 ||<br />
|-<br />
| || 10.50.252.94 ro1 || 10.50.252.95 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.96 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.97 fff-gw-cd2 ||<br />
|-<br />
| || 10.50.252.98 fff-gw-cd2 || 10.50.252.99 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.100 fff-gw-cd2 || 10.50.252.101 has2 ||<br />
|-<br />
| || 10.50.252.102 fff-gw-cd2 || 10.50.252.103 fff-gw-m1 ||<br />
|-<br />
| || 10.50.252.104 fff-gw-cd2 || 10.50.252.105 fff-dns-cd1 ||<br />
|-<br />
| || 10.50.252.106 fff-fr1-arm || 10.50.252.107 ro1 ||<br />
|-<br />
| || 10.50.252.250 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.251 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.252 Testsystem von [[Benutzer:ChristianD]] || 10.50.252.253 Testsystem2 von [[Benutzer:ChristianD]] ||<br />
|-<br />
|}<br />
<br />
=== 10.83.0.0/16 ===<br />
<br />
{|<br />
! !! Bereich !! Bereitgestellt durch<br />
|-<br />
! 10.83.0.0/16 || decentraliced keyXchange network ||<br />
|-<br />
| || <font color="grey">10.83.0.1 - 10.83.255.254</font> || <br />
|-<br />
! 10.83.0.0/22 || Trainstation ||<br />
|-<br />
| || 10.83.0.1 - 10.83.0.64 || static<br />
|-<br />
| || 10.83.1.0 - 10.83.2.0 || fff-nue2-gw2.fff.community<br />
|-<br />
! 10.83.4.0/22 || Nuremberg ||<br />
|-<br />
! 10.83.8.0/22 || Furth ||<br />
|-<br />
| || 10.83.8.1 || fff-gw-cd1.fff.community<br />
|-<br />
| || 10.83.9.0 - 10.83.9.255 || DHCP fff-gw-cd1.fff.community<br />
|-<br />
! 10.83.252.0/22 || Master IPs || for use as /32 routed IPs withing L3 network<br />
|-<br />
| || 10.83.252.1/32 || fff-nue2-gw2.gw.fff.community ||<br />
|-<br />
| || 10.83.252.2/32 || fff-nue2-gw1.gw.fff.community ||<br />
|-<br />
| || 10.83.252.3/32 || fff-gw-cd1.gw.fff.community ||<br />
|-<br />
| || 10.83.252.4/32 || fff-gw-m2.gw.fff.community ||<br />
|-<br />
|}<br />
<br />
== Statische IP-Adressen ==<br />
Dienste müssen Ihre IP-Adressen natürlich aus dem Subnetz beziehen, in welchem sie angeschlossen sind. Damit es keine Konflikte gibt, muss die IP-Adresse hier registriert werden.<br />
<br />
=== Default Hood ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.16.0 – 10.50.17.255 || || IP-Bereich Default Hood || <br />
|-<br />
| 10.50.16.2 || fff-nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.16.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.16.11 || c.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.21 || rns3.franken.ff || DNS PoC - Recursor #3 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.16.100 || netmon.freifunk-franken.de || || [[Server#si1|Details]]<br />
|-<br />
| 10.50.16.112 ||???.franken.ff || Raspberry Pi, Test owncloud, FTP || MartinS<br />
|-<br />
| 10.50.16.128 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.150 ||Diagnose ChristianD || Diagnose ChristianD || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.16.200 ||???.franken.ff || Fileserver || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.16.212 ||???.franken.ff || NAS, verschiedene Services || JomJom<br />
|-<br />
| 10.50.16.222 ||???.franken.ff || VM, mom. nur Test || pixelchrome<br />
|-<br />
| 10.50.17.112 ||???.franken.ff || Webserver, Tests || wolli112<br />
|}<br />
<br />
=== Hood Fürth ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.32.0 – 10.50.32.255 || || IP-Bereich Fürth Hood || <br />
|-<br />
| 10.50.32.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.32.3 || fff-uk1.freifunk-franken.de || || [[Server#fff-uk1|Details]]<br />
|-<br />
| 10.50.32.4 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|- <br />
| 10.50.32.5 || [[fff-nue2|fff-nue2-gw1]] || Gateway || [[Benutzer:RedDog|RedDog]] [[Benutzer:Mayosemmel|Mayosemmel]] [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.6 || frei || ||<br />
|- <br />
| <font color="grey"> 10.50.32.7 </font>||<font color="grey"> (frei) </font> || ||<br />
|-<br />
| 10.50.32.26 || Test-PI || Statische IP des RasPI für Testzwecke || [[Benutzer:Hobo|Hobo]] <br />
|-<br />
| 10.50.32.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.32.70 || NAT für priv. Netz || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.71 || testbridgeclient.bridge.fff.community || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.100 || MicroNAS || anonymous FTP (10GB) || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.101 || Wetterstation || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Daten bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.102 || Wetterkamera || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Bilder bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.108 || williams || privater PC || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.109 || Raspi || Raspi Server im Höffner || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.110 || - || - || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.111 || stmichael.bridge.ws13.fff.community || Nanobeam M5 Bridge als AP auf St. Michael Richtung DelphiN || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.112 || ws13.bridge.stmichael.fff.community || Nanobeam M5 Bridge als Client bei DelphiN. Richtung St. Michael || [[Benutzer:delphiN|delphiN]], [[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.113 || stmichael.bridge.hoeffner.fff.community || Bridge als AP auf St. Michael. Richtung Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.114 || hoeffner.bridge.stmichael.fff.community || Bridge als Client bei Hoeffner. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.115 || clockwork.bridge.stmichael.fff.community || Bridge als Client bei Clockwork. Richtung St. Michael || [[Benutzer:clockwork|clockwork]],[[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]], <br />
|-<br />
| 10.50.32.117 || || ToughSwitch Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.118 || || ToughSwitch auf WS13 || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.119 || || ToughSwitch auf StMichael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.120 || || ToughSwitch im Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.121 || || Bridge als AP auf St. Michael. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.122 || || Bridge als Client in Europaallee. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.123 || || Reserviert: Bridge als AP auf Hardhöhe. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.124 || || Bridge als Client in Europaallee. Richtung Hardhöhe || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.150 || ChristianD's PC || FFF-Netz ohne Internet || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.151 || feste Laptop IP || Für Speedtests mit manuellen Gateway || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.152 || RasPi || Testsystem || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.170 || HoeffnerPrinter || Drucker Computerraum Höffner || [[Benutzer:delphiN|delphiN]] <br />
|-<br />
| 10.50.32.199 || || Ralphs home-server ftp/http || [[Benutzer:dk5ras|dk5ras]] <br />
|}<br />
<br />
=== Hood Nürnberg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.40.0 – 10.50.40.255 || || IP-Bereich Nürnberg Hood || <br />
|-<br />
|<strike>10.50.40.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.40.6 || fff-bbg-tmp|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.7 || fff-gw-yaga|| || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.40.8 || fff-bbg|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.10 || FFF-GW-M1 || || [[Server#FFF-GW-M1|Details]]<br />
|-<br />
| 10.50.40.11 || a.ns.franken.ff || DNS PoC - Master || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.12 || b.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.20 || - – - || Direct Connect HUB || [[Benutzer:TheFroggy|TheFroggy]]<br />
|-<br />
| 10.50.40.21 || rns1.franken.ff || DNS PoC - Recursor #1 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.22 || rns2.franken.ff || DNS PoC - Recursor #2 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| <strike>10.50.40.40</strike> || <strike>fff-synology.freifunk-franken.de</strike> || Umgezogen nach NBGLand || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.40.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.40.51 || mayo-test.fff.community || || [[Benutzer:mayosemmel|mayosemmel]]<br />
|-<br />
| 10.50.40.52 || VPN ins FF || || [[Benutzer:mayosemmel|mayosemmel]]<br />
|-<br />
| 10.50.40.66 || flightradar.freifunk-franken.de || Dump1090 || [[Benutzer:Sixkiller6kl|sixkiller6kl]]<br />
|-<br />
| 10.50.40.88 || Knotenpunkt || Test-Server || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.98 || jabber.pm-ib.de || Jabber-Server || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.99 || K4CG || Dinge-Tester || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.100 || K4CG || Dinge-Tester || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.101 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.102 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.103 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.110 || ff_br_Spenglerstr || 5-GHz-Bridge Spenglerstr --> Johannis || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.111 || ff_Johannis || 5-GHz-Bridge Johannis --> Spenglerstr || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.120 || -- || 5-GHz-Access Point (Schniegling) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.121 || -- || 5-GHz-Client (Naturfreundehaus Nürnberg Mitte) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.122 || -- || 5-GHz-Client (Quelle GU) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.123 || -- || 5-GHz-AccessPoint (Quelle, Internetanbindung) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.130 || ff_nhgbr_Johnny || 5-GHz-Master (Standort Spenglerstr) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.131 || ff_nhgbr_NHG || 5-GHz-Slave (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.132 || ff_NHG_Osten || 5-GHz-Master (Standort Nachbarschaftshaus Goho, Richtung Osten) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.135 || ff_nhgswitch_NHG || POE-Switch (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.140 || ff_TS_PoE_tmp || 5-Port POE-Switch (für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.141 || ff_NS_M5_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.142 || ff_NS_M5_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.143 || ff_PB_5AC_500_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.144 || ff_PB_5AC_500_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.145 || ff_nhgbrsüd_M5loco_Master || 5-GHz-Master (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.146 || ff_Bauerngassebr_M5loco_Slave || 5-GHz-Slave (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.200 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Client, Routerfernwartung || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.206 || --- || lokale Dienste || [[Benutzer:meskal|meskal]]<br />
|-<br />
| 10.50.40.201 – 10.50.40.205|| Test || bitte vorläufig freihalten, danke || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.230 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.231 ||???.franken.ff || Juniper SRX (VRF) || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.232 ||???.franken.ff || Raspberry Pi || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.233 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.234 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
| 10.50.43.165 || fffsvr01.franken.freifunk.net || SMB, FTP Server 250GB || [[Benutzer:ManuelS|ManuelS]]<br />
|}<br />
<br />
=== Hood Ansbach ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.48.0 – 10.50.48.255 || || IP-Bereich Ansbach Hood || <br />
|-<br />
| 10.50.48.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.48.3 || fff-gw-cdfue1 || || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| 10.50.48.20 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.21 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.48.230 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.231 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.232 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.233 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.234 || || mom. nur Test || JuzeCr<br />
|}<br />
<br />
=== Hood Hassberge ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.56.0 – 10.50.56.255 || || IP-Bereich Hassberge Hood || <br />
|-<br />
| 10.50.56.1 || fff-has1|| || [[Server#fff-has1|Details]] <br />
|-<br />
| 10.50.56.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]] <br />
|-<br />
| 10.50.56.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.56.7 || fff-roffl|| || [[Server#fff-roffl|Details]]<br />
|-<br />
| 10.50.56.8 || fff-has3 || || [[Server#fff-has3|Details]] <br />
|-<br />
| 10.50.56.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.56.100 || ff_MT_RB260GSP_PoE_Ost || 5-Port POE-Switch (Ostheim-Hofheim) || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.101 || ff_NS_M5_Master_Ostheim_Hofheim || 5-GHz-Master (Richtfunkstrecke von Ostheim nach Hofheim) || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.40.102 || ff_NS_M5_Slave_Hofheim_Ostheim || 5-GHz-Slave (Richtfunkstrecke von Ostheim nach Hofheim) || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.103 || ff_MT_RB260GSP_PoE_Hoh || 5-Port POE-Switch (Hofheim-Ostheim) || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| Bitte den Bereich 10.50.56.120 – 10.50.56.129 für [[Benutzer:Plocker|Plocker]] frei lassen<br />
|-<br />
| 10.50.56.123 || Teeworlds-Game-Server || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.124 || OwnCloud + Wiki || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.125 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.126 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.132 ||<strike> Webserver + MUD? || || [[Benutzer:PeterPhilipp|area52]]</strike><br />
|}<br />
<br />
=== Hood Hassberge Süd ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.60.0 – 10.50.60.255 || || IP-Bereich HassbergeSued Hood ||<br />
|-<br />
|<strike> 10.50.60.1</strike> || <strike>fff-has1 </strike>|| || [[Server#fff-has1|Details]]<br />
|-<br />
| 10.50.60.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.60.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.60.7 || fff-roffl|| || [[Server#fff-roffl|Details]] <br />
|-<br />
| 10.50.60.10 || Webcam Meehäusle Parkplatz|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.11 || Webcam Meehäusle Biergarten|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.100 /mediawiki || Webserver Mediawiki (in progress: Wikipedia(de)offline mirror)|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.101 /wiki || Raspi Webserver mit MediaWiki (Haßberge Wiki)|| || [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Erlangen ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.64.0 – 10.50.64.255 || || IP-Bereich Erlangen Hood || <br />
|-<br />
| 10.50.64.3 || fff-gw-yaga || || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.64.4 || fff-gw-kwadro || || [[Server#fff-gw-kwadro|Details]]<br />
|-<br />
| 10.50.64.10 || radiator.franken.ff || || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.11 || voip-1.radiator.franken.ff || Outernet, VoIP mittels SIP || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.12 || cam-1.radiator.franken.ff || IP-Cam || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.20 || radiatrix.franken.ff || geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.21 || cam-1.radiatrix.franken.ff || IP-Cam, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.22 || voip-1.radiatrix.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.30 || long.franken.ff || geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.31 || cam-1.long.franken.ff || IP-Cam || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.33 || voip-1.long.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.40 |||| Streaming Erlangen (im Aufbau) || [[Benutzer:R.funkt|R.funkt]]<br />
|-<br />
| 10.50.64.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.64.60 || gate3 || Dev || [[Benutzer:Jonas-bebe|Jonas-bebe]]<br />
|-<br />
| 10.50.64.70 |||| Raspi-Test || [[Benutzer:Dieter123|Dieter123]]<br />
|-<br />
| 10.50.64.78 |||| IP-CAM || [[Benutzer:moonrat|moonrat]]<br />
|-<br />
| 10.50.64.79 |||| IP-CAM || [[Benutzer:moonrat|moonrat]]<br />
|}<br />
<br />
=== Hood Würzburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.72.0 – 10.50.79.255 || || IP-Bereich Würzburg Hood || <br />
|-<br />
| 10.50.72.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.72.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.72.6 || fff-wue1|| || [[Server#fff-wue1|Details]] <br />
|-<br />
| 10.50.72.7 || kleeV2|| || [[Server#kleeV2|Details]] <br />
|-<br />
| 10.50.72.9 || Raspi-test|| || [[MisterCrumble|MisterCrumble]]<br />
|-<br />
| 10.50.72.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.72.72 || WikipediaClon || Soll ein Clon der Wikipedia werden. || [[Benutzer:Luensche|Luensche]]<br />
|-<br />
| 10.50.72.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood BGL ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.80.0 – 10.50.87.255 || || IP-Bereich BGL Hood || <br />
|-<br />
| 10.50.80.1 || watzmann || ||<br />
|-<br />
| 10.50.80.2 || staufen || ||<br />
|}<br />
<br />
=== Hood Nürnberger-Land ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.88.0 – 10.50.95.255 || || IP-Bereich NbgLand Hood || <br />
|-<br />
| 10.50.88.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.88.10 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.11 || fff-gw-cdnbgland2 || Gateway (Testbetrieb) || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.40 || fff-synology.freifunk-franken.de || Umzug nach Hood-Teilung || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.88.170 ||???.franken.ff || 5-GHz Richtfunk AP || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.171 ||???.franken.ff || 5-GHz Richtfunk Client || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.172 ||???.franken.ff || VM zum Testen || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood Aschaffenburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.96.0 – 10.50.103.255 || || IP-Bereich Aschaffenburg || <br />
|-<br />
| 10.50.96.x || fff-res|| || <br />
|-<br />
| 10.50.96.3 || fff-has || Gateway [[Server#fff-has|Details]]<br />
|| [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Hof ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.104.0 – 10.50.111.255 || || IP-Bereich Hof || <br />
|-<br />
| 10.50.104.1 || fff-has1 || Gateway [[Server#fff-has1|Details]]<br />
|| [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.104.2 || fff-fr1-arm || Gateway || [[User:RedDog]]<br />
|-<br />
| 10.50.104.10 || fff-gw-cdhof1 || Gateway || ChristianD<br />
|}<br />
<br />
=== Hood FabLabnbg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.132.0 – 10.50.134.255 || || IP-Bereich FabLabnbg || <br />
|-<br />
| 10.50.132.1 || fablab || Gateway FabLabnbg || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|-<br />
| 10.50.132.2 || Switch || Switch || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|-<br />
| 10.50.132.9 || Raspberry Pi || Für Alfredmaster || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.132.10 || 5GHz Test || 5GHz Test || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|}<br />
<br />
=== Hood Hardhöhe ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.130.0 – 10.50.131.255 || || IP-Bereich Hardhöhe || <br />
|-<br />
| 10.50.130.1 || fff-gw-db0fue1 || Gateway Hardhöhedach || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.11 || fff-5gs1-hhd || erste LBE-5AC-16-120 || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.12 || fff-5gs2-hhd || zweite LBE-5AC-16-120 || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|}<br />
<br />
=== Hood Aux ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
!10.50.240.1 – 10.50.247.254 || || IP-Bereich aux Hood || <br />
|-<br />
| 10.50.240.1 || fff-bbg || ||<br />
|-<br />
| 10.50.240.2 || fff-fra1 || ||<br />
|-<br />
| 10.50.240.3 || fff-gw-cdaux2 || ||<br />
|-<br />
| 10.50.240.20 || || Testgateway Flo für Hotel Busch |||<br />
|-<br />
| 10.50.240.11 || AP.bridge1.hoeffner.fff.community || Bridge AP Höffner || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.12 || S01.bridge1.hoeffner.fff.community || Bridge Station Hardhöhe || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.100 || fff-client-auxcd1 || Client zur Fernwartung aux || [[Benutzer:ChristianD|ChristianD]] ||<br />
|}<br />
<br />
= BSSID =<br />
<br />
{|<br />
! BSSID !! Hood !!<br />
|-<br />
| 00:ca:ff:ee:ba:be || legacy ||<br />
|-<br />
| ca:ff:ee:ba:be:00 || Trainstation ||<br />
|-<br />
| ca:ff:ee:ba:be:02 || Fürth || <br />
|-<br />
| ca:ff:ee:ba:be:03 || Nürnberg ||<br />
|-<br />
| ca:ff:ee:ba:be:04 || FabLabNbg ||<br />
|-<br />
| ca:ff:ee:ba:be:05 || Hardhöhe ||<br />
|}</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Liste_bekannter_Aux-FW_Router&diff=6616
Liste bekannter Aux-FW Router
2016-05-17T17:04:23Z
<p>Green: </p>
<hr />
<div>Um den Überblick über die mit Aux-FW geflashten Router zu behalten, wird eine Übersichtstabelle über die bekannten (d.h. zurückgemeldeten) Router geführt.<br />
<br />
{|<br />
! Routername !! Router-MAC !! gemeldet von !! gemeldet am !! Bemerkungen<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1317 Notunterkunft Turnhalle] || 14CC204D4786 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1318 Notunterkunft Turnhalle1] || 30B5C2AC26D8 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://monitoring.freifunk-franken.de/routers/5728883f9369c349edbc8379 ArnsteinerNetz0001] || 30:b5:c2:bd:77:ba || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 20160310<br />
|-<br />
|[https://monitoring.freifunk-franken.de/routers/56460db244ce6e072838481d ArnsteinerNetz0002] || 30.b5:c2:bd:78:86 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 20160310<br />
|-<br />
|[https://monitoring.freifunk-franken.de/routers/5633ade544ce6e071cafd6ce ArnsteinerNetz0005] || 30:b5:c2:88:47:14 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 20160310<br />
|-<br />
|[https://monitoring.freifunk-franken.de/routers/5640c43144ce6e5f95d6bdba ArnsteinerNetz0006] || 30:b5:c2:88:4e:00 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 20160310<br />
|-<br />
|[https://monitoring.freifunk-franken.de/routers/56239dae44ce6e4afed6d09c ArnsteinerNetz002] || 30:b5:c2:d9:c8:ae || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 20160310<br />
|-<br />
|[https://monitoring.freifunk-franken.de/routers/5623a5e344ce6e4afed6d09d ArnsteinerNetz004] || 30:b5:c2:d9:c6:de || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 20160310<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=583 WS13W01WR1043] || e8:de:27:fd:2b:aa || [https://netmon.freifunk-franken.de/user.php?user_id=6 delphiN] || 03.11.2015 || Beta 2 Testbetrieb<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1768 HabuRef01] || 30B5C20E8AE0 || [https://netmon.freifunk-franken.de/user.php?user_id=438 DerMichy] || 15.11.2015 || Pending installation in Hammelburg, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1766 Tannenberg01] || 60:E3:27:2A:56:46 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1769 Tannenberg02] || 30:B5:C2:E2:FD:EE || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1770 Tannenberg03] || 60:E3:27:2A:58:E4 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2066 Tannenberg04] || 60:E3:27:59:E3:C8 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 05.01.2016 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1751 AHKRockenbrunner1] || A0:F3:C1:76:4F:20 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=860 AHKRockenbrunner2] || C0:4A:00:0B:A8:94 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=856 AHKRockenbrunner3] || C4:6E:1F:F5:F4:AC || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1861 AHKRockenbrunner4] || 30:B5:C2:81:08:DA || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1650 OBT1] || 14cc2030e9ce || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1651 OBT2] || 14CC2030EA0C || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1659 OBT3] || 30B5C2D9B4AE || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1781 OBT4] || 30B5C2D9BD72 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1782 OBT5] || 30B5C2D9B522 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1842 ap1.refugees.kleinheubach] || 30:B5:C2:B0:56:0E || [https://netmon.freifunk-franken.de/user.php?user_id=446 oswald] || 30.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1848 stein-knauppstr-04] || 10FEEDCD9B3C || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1904 AsylcenterEbelsbach] || 30B5C2E301A6 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1319 AsylcenterEbelsbach1] || 30B5C2CB356C || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1591 refugees21.wue] || 68:72:51:2c:2f:9c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1602 refugees22.wue] || 12:bc:f9:69:d3:5c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1610 refugees23.wue] || 68:72:51:2c:30:bb || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2005 wue.N2N-ev.refugees.aux.001] || 60:e3:27:bd:ce:08 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2004 wue.N2N-ev.refugees.aux.002] || 60:e3:27:c7:30:3c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1819 wue.N2N-ev.refugees.aux.003] || 60:e3:27:c7:2f:d6 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2014 wue.N2N-ev.refugees.aux.004] || 14:cc:20:87:3c:5e || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2010 wue.N2N-ev.refugees.aux.005] || 60:e3:27:82:00:72 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2011 wue.N2N-ev.refugees.aux.006] || 60:e3:27:82:0a:3a || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2012 wue.N2N-ev.refugees.aux.007] || 68:72:51:2c:2c:28 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=2143 NotunterkunftGerbrunn0] || 30:B5:C2:3E:84:A2 || [https://netmon.freifunk-franken.de/user.php?user_id=630 dasaweb] || 17.01.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=1260 aux.refugees3.wue] || 30B5C222F3C4 || [https://netmon.freifunk-franken.de/user.php?user_id=433 malleze_wue] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=1261 aux.refugees4.wue] || 30B5C222D3B8 || [https://netmon.freifunk-franken.de/user.php?user_id=433 malleze_wue] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=1339 aux.refugees7.wue] || 647002F71C1E || [https://netmon.freifunk-franken.de/user.php?user_id=433 malleze_wue] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=1865 aux.refugees27.wue] || 14CC20E3E9A2 || [https://netmon.freifunk-franken.de/user.php?user_id=433 malleze_wue] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=2434 aux.refugees40.wue] || 30B5C222D3B8 || [https://netmon.freifunk-franken.de/user.php?user_id=433 malleze_wue] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=1368 refugees14.wue] || C46E1F2B9B90 || [https://netmon.freifunk-franken.de/user.php?user_id=459 DiLeGreen] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=2317 ap2.refugees.kleinheubach] || 14:cc:20:cd:4e:46 || [https://netmon.freifunk-franken.de/user.php?user_id=446 oswald] || 16.02.2016 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1586 OBT6] || c4:6e:1f:a2:53:4a || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 05.03.2016 ||<br />
|}<br />
<br />
Mehr Infos über die Aux-Firmware [https://wiki.freifunk-franken.de/w/Was_ist_die_aux_Firmware hier.]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Server/fff-fra1/Log&diff=6601
Server/fff-fra1/Log
2016-05-15T16:46:23Z
<p>Green: /* 15.05.2016 */</p>
<hr />
<div>__NOTOC__<br />
<br />
== 08.10.15 ==<br />
* Passwort für fffranken geändert.<br />
* Passwort für root geändert.<br />
<br />
== 09.10.15 ==<br />
=== sudo installieren (als root) ===<br />
<code><br />
apt-get update<br />
<br />
apt-get install sudo<br />
</code><br />
<br />
=== Neuen User delpiN angelegt (als root) ===<br />
<code><br />
adduser delphin<br />
<br />
adduser delphin sudo<br />
<br />
nano /etc/sudoers<br />
</code><br />
<pre><br />
# User privilege specification<br />
root ALL=(ALL:ALL) ALL<br />
delphin ALL=(ALL:ALL) ALL<br />
</pre><br />
<br />
=== fail2ban installiert und eingerichtet ===<br />
<code><br />
sudo apt-get install fail2ban<br />
<br />
sudo nano /etc/fail2ban/jail.local<br />
<br />
sudo /etc/init.d/fail2ban restart<br />
</code><br />
<br />
=== SSH Port geändert ===<br />
Es sollte einen Port gewählt werden der nicht bereits vergeben ist (Liste vergebener Ports: ''more /etc/services'')<br />
<br />
<code><br />
sudo nano /etc/ssh/sshd_config<br />
</code><br />
<pre><br />
# What ports, IPs and protocols we listen for<br />
Port 8024<br />
</pre><br />
<br />
<code><br />
/etc/init.d/ssh restart<br />
</code><br />
<br />
=== SSH Login nur über Key erlauben ===<br />
<code><br />
sudo nano /etc/ssh/sshd_config<br />
</code><br />
<pre><br />
RSAAuthentification no<br />
AuthorizedKeysFile %h/.ssh/authorized_keys<br />
IgnoreUserKnowHosts yes<br />
ChallengeResponseAuthentication no<br />
PasswordAuthentication no<br />
</pre><br />
<br />
<code><br />
sudo /etc/init.d/ssh restart<br />
</code><br />
<br />
=== vnstat installiert ===<br />
<code><br />
sudo apt-get install vnstat<br />
</code><br />
<br />
=== mtr installiert ===<br />
<code><br />
sudo apt-get install mtr<br />
</code><br />
<br />
== 11.10.15 ==<br />
* 3x User hinzugefügt (mifritscher, christiand, green) (login via ssh key only)<br />
* 3 Usern sudo Rechte eingeräumt (/etc/sudoers)<br />
* sudo ohne erneute Passwordeingabe (sudo visudo; username ALL=(ALL) NOPASSWD: ALL)<br />
* screen installiert<br />
* dist-upgrade<br />
* BTAMAN compilieren<br />
* batctl compiliert<br />
* fastd installiert<br />
* kein OpenVPN<br />
* DHCP<br />
* bind9<br />
* wget https://mifritscher.de/austausch/olsrd/jessie/olsrd_0.6.8.1-1_amd64.deb<br />
* wget https://mifritscher.de/austausch/olsrd/jessie/olsrd-plugins_0.6.8.1-1_amd64.deb<br />
* dpkg -i olsrd-plugins_0.6.8.1-1_amd64.deb<br />
* dpkg -i olsrd_0.6.8.1-1_amd64.deb<br />
<br />
* Packete auf FTP kopiert:<br />
** http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd-plugins_0.6.8.1-1_amd64.deb<br />
** http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd_0.6.8.1-1_amd64.deb<br />
<br />
<code><br />
# device: bat0<br />
iface bat0 inet manual<br />
post-up ifconfig $IFACE up<br />
##Einschalten post-up:<br />
# IP des Gateways am B.A.T.M.A.N interface:<br />
post-up ip addr add 10.50.240.2/21 dev $IFACE<br />
# Regeln, wann die fff Routing-Tabelle benutzt werden soll: <br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.0.0.0/8 table fff<br />
post-up ip rule add to 10.0.0.0/8 table fff<br />
# Route in die Aux Hood:<br />
post-up ip route add 10.50.240.0/21 dev $IFACE table fff<br />
# Start des DHCP Servers:<br />
### post-up invoke-rc.d isc-dhcp-server restart<br />
<br />
##Ausschalten post-down:<br />
# Loeschen von oben definieren Routen, Regeln und Interface: <br />
post-down ip route del 10.50.240.0/21 dev $IFACE table fff<br />
post-down ip rule del from 10.0.0.0/8 table fff<br />
post-down ip rule del to 10.0.0.0/8 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ifconfig $IFACE down<br />
<br />
# VPN Verbindung in die Aux Hood<br />
iface fffauxVPN inet manual<br />
post-up batctl -m bat0 if add $IFACE<br />
post-up ifconfig $IFACE up<br />
post-up ifup bat0<br />
post-down ifdown bat0<br />
post-down ifconfig $IFACE down<br />
</code><br />
* Fastd Skript einfügen<br />
<code><br />
christiand@fff-fra1:~$ cat /etc/fastd/fff_aux_fastd.sh<br />
#!/bin/sh<br />
<br />
SERVERNAME="fff-fra1"<br />
<br />
hood="def"<br />
project="fffaux"<br />
port=10000<br />
<br />
SERVERNAME="$SERVERNAME.$hood"<br />
<br />
hostname=$SERVERNAME<br />
<br />
if [ ! -d /etc/fastd ]<br />
then<br />
mkdir /etc/fastd<br />
fi<br />
<br />
if [ ! -d /etc/fastd/$project.$hood ]<br />
then<br />
mkdir /etc/fastd/$project.$hood<br />
mkdir /etc/fastd/$project.$hood/peers<br />
<br />
#fastd config<br />
(<br />
echo "# Log warnings and errors to stderr"<br />
echo "log level error;"<br />
echo "# Log everything to a log file"<br />
echo "log to syslog as \"${project}${hood}\" level info;"<br />
echo "# Set the interface name"<br />
echo "interface \"${project}${hood}VPN\";"<br />
echo "# Support xsalsa20 and aes128 encryption methods, prefer xsalsa20"<br />
echo "#method \"xsalsa20-poly1305\";"<br />
echo "#method \"aes128-gcm\";"<br />
echo "method \"null\";"<br />
echo "# Bind to a fixed port, IPv4 only"<br />
echo "bind any:${port};"<br />
echo "# Secret key generated by \"fastd --generate-key\""<br />
echo "secret \"$(fastd --generate-key | grep -i Secret | awk '{print $2}')\";"<br />
echo "# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)"<br />
echo "# (see MTU selection documentation)"<br />
echo "mtu 1426;"<br />
echo "on up \"/etc/fastd/${project}.${hood}/up.sh\";"<br />
echo "on post-down \"/etc/fastd/${project}.${hood}/down.sh\";"<br />
echo "# Include peers from the directory 'peers'"<br />
echo "include peers from \"/etc/fastd/${project}.${hood}/peers\";"<br />
echo "secure handshakes no;"<br />
) >> "/etc/fastd/$project.$hood/$project.$hood.conf"<br />
<br />
#fastd-up<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifdown \$INTERFACE"<br />
) >> /etc/fastd/$project.$hood/down.sh<br />
<br />
chmod +x /etc/fastd/$project.$hood/down.sh<br />
<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifup \$INTERFACE" >> /etc/fastd/$project.$hood/up.sh<br />
) >> /etc/fastd/$project.$hood/up.sh<br />
chmod +x /etc/fastd/$project.$hood/up.sh<br />
fi<br />
<br />
pubkey=$(fastd -c /etc/fastd/$project.$hood/$project.$hood.conf --show-key --machine-readable)<br />
port=$(grep ^bind /etc/fastd/$project.$hood/$project.$hood.conf | cut -d: -f2 | cut -d\; -f1)<br />
<br />
# fire up<br />
if [ "$(/sbin/ifconfig -a | grep -i ethernet | grep ${project}${hood}VPN)" = "" ]<br />
then<br />
/bin/rm /var/run/fastd.$project.$hood.pid<br />
fastd -c /etc/fastd/$project.$hood/$project.$hood.conf -d --pid-file /var/run/fastd.$project.$hood.pid<br />
fi<br />
<br />
# register<br />
wget -T15 -q "http://keyserver.freifunk-franken.de/${project}/?name=$hostname&port=$port&key=$pubkey" -O /tmp/fastd_${project}.${hood}_output<br />
if [ "$?" != "0" ]<br />
then<br />
echo "Update failed"<br />
echo "Exiting, no clean up, no refresh"<br />
exit<br />
fi<br />
<br />
touch /tmp/fastd_${project}.${hood}_starting<br />
<br />
filenames=$(cat /tmp/fastd_${project}.${hood}_output| grep ^#### | sed -e 's/^####//' | sed -e 's/.conf//g')<br />
for file in $filenames<br />
do<br />
grep -A100 ^####$file.conf$ /tmp/fastd_${project}.${hood}_output | grep -v ^####$file.conf$ | grep -m1 ^### -B100 | grep -v ^### | sed 's/ float;/;/g' > "/etc/fastd/$project.$hood/peers/$file"<br />
echo 'float yes;' >> "/etc/fastd/$project.$hood/peers/$file"<br />
done<br />
<br />
#find old peers<br />
OLD=$(find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print)<br />
<br />
if [ -n "${OLD}" ] ; then<br />
echo "Lösche alte:"<br />
echo $OLD<br />
<br />
find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print | xargs /bin/rm /tmp/fastd_${project}.${hood}_starting<br />
fi<br />
<br />
#reload<br />
kill -HUP "$(cat /var/run/fastd.$project.$hood.pid)"<br />
<br />
exit 0<br />
</code><br />
* Hostname geändert<br />
* IP Forwarding aktiviert<br />
* Fastd Skript ausführbar (chmod +x /etc/fastd/fff_aux_fastd.sh)<br />
* fastd Script gestartet, interface Name angepasst<br />
dabei gab es Probleme, erst beim 2. Start des fastd Scripts kamen die Interface richtig hoch.<br />
* fastd Script in crontab und rc.local<br />
* dns / bind9 als caching nameserver (8.8.8.8, 10.50.240.1)<br />
* batman gw selection 1:1 aus anleitung<br />
* bat0 als interface dhcp-server<br />
* dhcp config:<br />
<code><br />
## Freifunk Franken <br />
option domain-name "fff.community"; <br />
option domain-name-servers 10.50.240.2; <br />
authoritative; <br />
## aux <br />
subnet 10.50.32.0 netmask 255.255.248.0 { # Netzwerk und Netzmaske der Aux<br />
range 10.50.242.0 10.50.243.255; # IP-Range die der DHCP-Server i<br />
option routers 10.50.240.2; # Default-Gateway, dass Clients <br />
option domain-name-servers 10.50.240.2; # Name-Server, die Clients mitge<br />
}<br />
</code><br />
* gre Tunnel nach kleeV2 und bbg / klappt noch nicht / erneuter test nach einrichten von olsr<br />
<br />
* olsr installiert. interfaces nach kleeV2, bbg<br />
* tunnel nach kleev2 funktioniert<br />
* Routing Tabelle wird über kleev2 ausgetauscht<br />
* DHCP Subnetz nach 10.50.240.0/21 korrigiert<br />
* Probleme mit dem KeyXchange -> Fix von Tim, fastd Neustart<br />
* Client bezieht keine IP, Batman zeigt keinen Hop zum mit aux-FW geflashten Router<br />
* WR841ND mit Beta der Aux-Firmware geflascht. Nach langer Fehlersuche funktioniert B.A.T.M.A.N auf Router und GW. Zugang auf Router schwierig -> Anschluss von Client port und WAN port an Heimrouter. Später: Selbstheilung ohne erkennbare Einwirkung.<br />
* DHCP manuell gestartet, aus irgendwelchen Gründen nicht bei automatisch bei reboot.<br />
* Masquerading auf dem GW aktiviert: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE. Eintrag in /etc/rc.local<br />
* Test: Umleiten des Traffic von kleev2 nach fra1, indem neue default route in kleev2 definiert wurde ("ip route add default via 10.50.252.48 table fff") -> Erfolgreich<br />
<br />
== 12.10.2015 ==<br />
* apache2 installiert<br />
* snpd und mrtg nach https://wiki.freifunk-franken.de/w/Portal:Netz/Statistiken eingerichtet. Abweichung: statt CPU.cfg system.mfg und kein eigener index.<br />
* apache2 index in /etc/apache2/sites-available/000-default.conf nach /var/www geändert.<br />
* robots.txt -> /var/www: No searchbot crawling<br />
* vnstat nach http://www.tecmint.com/vnstat-php-frontend-for-monitoring-network-bandwidth/ eingerichtet. Databases "vnstat -u -i INTERFACE" und php-Anzeige /var/www/vnstat/config.php für eth0, bat0, kleeV2, bbg, fffauxdefVPN<br />
* Kopie von dhcpd-pool und dhcp-statistics.sh nach /usr/local/bin, Eintrag von dhcp-statistics.sh in die crontab (alle 5 Minuten)<br />
* In Crontab -> Tägliches Löschen von /var/www/topology-*.dot Dateien, die älter als 2 Tage sind (find /var/www -name "topology-????-??-??-??-??-??.dot" -mtime +2 | xargs rm -f)<br />
* Installation von phplot entsprechend http://www.phplot.com/phplotdocs/install.html<br />
* Webseite mit Monitoring Tools und Impressum hinzugefügt<br />
* ''curl'' installiert<br />
<br />
== 13.10.2015 ==<br />
* sudo user "dpaufler" angelegt. Key eingetragen.<br />
* node.js installiert:<br />
<code><br />
apt-get install npm<br />
<br />
sudo npm cache clean -f<br />
<br />
sudo npm install -g n<br />
<br />
sudo n stable<br />
<br />
sudo npm install npm -g<br />
</code><br />
<br />
== 14.10.2015 ==<br />
* [http://www.olsr.org/?q=jsoninfo_plugin OLSR_JsonInfo_Plugin] aktiviert. (Beispiel: http://84.200.64.42:9090/interfaces)<br />
<br />
== 17.10.2015 ==<br />
* Logrotate angepasst: 3 Tage backlogs ist Standard (/etc/logrotate.conf)<br />
* DHCP Ausgabe deaktiviert. Auszug aus /etc/log/rsyslogd.conf:<br />
<pre><br />
# /etc/rsyslog.conf Configuration file for rsyslog.<br />
#<br />
# For more information see<br />
# /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html<br />
<br />
<br />
##############<br />
#### DHCP ####<br />
##############<br />
#:programname, isequal, "dhcpd" /var/log/dhcpd.log<br />
:programname, isequal, "dhcpd" /dev/null<br />
:programname, isequal, "dhcpd" ~<br />
.<br />
.<br />
.<br />
</pre><br />
* Logrotate angepasst: 1 Tag backlog für /var/log/dhcpd.log (/etc/logrotate.conf)<br />
* Um logrotate von /var/lib/dhcp/dhcpd.leases zu ermöglichen, 5-minütigen cron-job eingerichtet, der folgendes ausführt: "chown -R dhcpd:dhcpd /var/lib/dhcp" (siehe https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1186662)<br />
<br />
== 19.10.2015 ==<br />
* iperf installiert<br />
* Logging-Regeln angepasst:<br />
** Verwerfen aller Logs von dhcpd. dump /etc/rsyslogd.conf<br />
<pre><br />
# /etc/rsyslog.conf Configuration file for rsyslog.<br />
#<br />
# For more information see<br />
# /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html<br />
<br />
<br />
##############<br />
#### DHCP ####<br />
##############<br />
#:programname, isequal, "dhcpd" /var/log/dhcpd.log<br />
:programname, isequal, "dhcpd" /dev/null<br />
:programname, isequal, "dhcpd" ~<br />
<br />
<br />
#################<br />
#### MODULES ####<br />
#################<br />
<br />
$ModLoad imuxsock # provides support for local system logging<br />
$ModLoad imklog # provides kernel logging support<br />
#$ModLoad immark # provides --MARK-- message capability<br />
<br />
# provides UDP syslog reception<br />
#$ModLoad imudp<br />
#$UDPServerRun 514<br />
<br />
# provides TCP syslog reception<br />
#$ModLoad imtcp<br />
#$InputTCPServerRun 514<br />
<br />
<br />
###########################<br />
#### GLOBAL DIRECTIVES ####<br />
###########################<br />
<br />
#<br />
# Use traditional timestamp format.<br />
# To enable high precision timestamps, comment out the following line.<br />
#<br />
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat<br />
<br />
#<br />
# Set the default permissions for all log files.<br />
#<br />
$FileOwner root<br />
$FileGroup adm<br />
$FileCreateMode 0640<br />
$DirCreateMode 0755<br />
$Umask 0022<br />
<br />
#<br />
# Where to place spool and state files<br />
#<br />
$WorkDirectory /var/spool/rsyslog<br />
<br />
#<br />
# Include all config files in /etc/rsyslog.d/<br />
#<br />
$IncludeConfig /etc/rsyslog.d/*.conf<br />
<br />
<br />
###############<br />
#### RULES ####<br />
###############<br />
<br />
#<br />
# First some standard log files. Log by facility.<br />
#<br />
auth,authpriv.* /var/log/auth.log<br />
*.*;auth,authpriv.none -/var/log/syslog<br />
#cron.* /var/log/cron.log<br />
daemon.* -/var/log/daemon.log<br />
kern.* -/var/log/kern.log<br />
lpr.* -/var/log/lpr.log<br />
mail.* -/var/log/mail.log<br />
user.* -/var/log/user.log<br />
<br />
#<br />
# Logging for the mail system. Split it up so that<br />
# it is easy to write scripts to parse these files.<br />
#<br />
mail.info -/var/log/mail.info<br />
mail.warn -/var/log/mail.warn<br />
mail.err /var/log/mail.err<br />
<br />
#<br />
# Logging for INN news system.<br />
#<br />
news.crit /var/log/news/news.crit<br />
news.err /var/log/news/news.err<br />
news.notice -/var/log/news/news.notice<br />
<br />
#<br />
# Some "catch-all" log files.<br />
#<br />
*.=debug;\<br />
auth,authpriv.none;\<br />
news.none;mail.none -/var/log/debug<br />
*.=info;*.=notice;*.=warn;\<br />
auth,authpriv.none;\<br />
cron,daemon.none;\<br />
mail,news.none -/var/log/messages<br />
<br />
#<br />
# Emergencies are sent to everybody logged in.<br />
#<br />
*.emerg :omusrmsg:*<br />
<br />
#<br />
# I like to have messages displayed on the console, but only on a virtual<br />
# console I usually leave idle.<br />
#<br />
#daemon,mail.*;\<br />
# news.=crit;news.=err;news.=notice;\<br />
# *.=debug;*.=info;\<br />
# *.=notice;*.=warn /dev/tty8<br />
<br />
# The named pipe /dev/xconsole is for the `xconsole' utility. To use it,<br />
# you must invoke `xconsole' with the `-file' option:<br />
# <br />
# $ xconsole -file /dev/xconsole [...]<br />
#<br />
# NOTE: adjust the list below, or you'll go crazy if you have a reasonably<br />
# busy site..<br />
#<br />
daemon.*;mail.*;\<br />
news.err;\<br />
*.=debug;*.=info;\<br />
*.=notice;*.=warn |/dev/xconsole<br />
</pre><br />
** Generell 3 Tage backlogs:<br />
<pre><br />
# see "man logrotate" for details<br />
# rotate log files daily<br />
daily<br />
<br />
# keep 3 days worth of backlogs<br />
rotate 3<br />
<br />
# create new (empty) log files after rotating old ones<br />
create<br />
<br />
# uncomment this if you want your log files compressed<br />
compress<br />
<br />
# packages drop log rotation information into this directory<br />
include /etc/logrotate.d<br />
<br />
# no packages own wtmp, or btmp -- we'll rotate them here<br />
/var/log/wtmp {<br />
missingok<br />
monthly<br />
create 0664 root utmp<br />
rotate 1<br />
}<br />
<br />
/var/log/btmp {<br />
missingok<br />
monthly<br />
create 0660 root utmp<br />
rotate 1<br />
}<br />
<br />
# system-specific logs may be configured here<br />
<br />
# system-specific logs may be configured here<br />
/var/log/dhcpd.log {<br />
rotate 1<br />
daily<br />
compress<br />
}<br />
</pre><br />
** Flush des DHCP lease files um 3.31 Uhr morgens. Dump crontab:<br />
<pre><br />
# m h dom mon dow command<br />
*/10 * * * * sh /etc/fastd/fff_aux_fastd.sh<br />
*/5 * * * * perl /etc/olsrd/dotDraw.pl > /dev/null 2>&1<br />
*/1 * * * * env LANG=C /usr/bin/mrtg /etc/mrtg/system.cfg > /dev/null 2>&1<br />
*/1 * * * * env LANG=C /usr/bin/mrtg /etc/mrtg/traffic.cfg > /dev/null 2>&1<br />
*/5 * * * * /usr/bin/vnstat -u >/dev/null 2>&1<br />
*/5 * * * * sudo dhcp-statistics.sh<br />
45 2 * * * find /var/www/topology/. -name "topology-????-??-??-??-??-??.dot" -mtime +1 | xargs rm -f<br />
#*/5 * * * * sudo chown -R dhcpd:dhcpd /var/lib/dhcp<br />
31 3 * * * sudo flush_dhcp.sh<br />
</pre><br />
** Flush des DHCP lease files um 3.31 Uhr morgens. Dump flush_dhcp.sh:<br />
<pre><br />
#!/bin/bash<br />
leasefile="/var/lib/dhcp/dhcpd.leases"<br />
<br />
/etc/init.d/isc-dhcp-server stop<br />
rm "$leasefile"<br />
rm "$leasefile~"<br />
touch "$leasefile"<br />
echo "" > "$leasefile"<br />
/etc/init.d/isc-dhcp-server start<br />
</pre><br />
<br />
== 22.10.2015 ==<br />
* Umstellung des IP-Bereichs auf 84.200.64.40/29<br />
<br />
== 23.10.2015 ==<br />
* Christohper Mäuer (von dotmanaged) User angelegt<br />
* Eintrag in der /etc/rc.local eingefügt:<br />
<pre><br />
#dhcp-server starten - geht beim Systemstart nicht, da dann das entsprechende Interface noch nicht da ist<br />
(sleep 30; /etc/init.d/isc-dhcp-server start) &<br />
</pre><br />
<br />
<br />
== 31.10.2015 ==<br />
* Revision der Logging-Rules: Dedicated log-file für snmpd<br />
* Auszug rsyslogd.conf:<br />
<pre><br />
###############<br />
#### SNMPD ####<br />
###############<br />
# Redirect snmpd<br />
:programname, isequal, "snmpd" /var/log/snmpd.log<br />
:programname, isequal, "snmpd" ~<br />
</pre><br />
<br />
* Auszug logrotate.conf:<br />
<pre><br />
/var/log/snmpd.log {<br />
rotate 3<br />
daily<br />
compress<br />
}<br />
</pre><br />
<br />
* Revision der logging rules: 3 Tage backlog für apache2. Dump /etc/logrotate.d/apache2:<br />
<pre><br />
/var/log/apache2/*.log {<br />
daily<br />
missingok<br />
rotate 3<br />
compress<br />
delaycompress<br />
notifempty<br />
create 640 root adm<br />
sharedscripts<br />
postrotate<br />
if /etc/init.d/apache2 status > /dev/null ; then \<br />
/etc/init.d/apache2 reload > /dev/null; \<br />
fi;<br />
endscript<br />
prerotate<br />
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \<br />
run-parts /etc/logrotate.d/httpd-prerotate; \<br />
fi; \<br />
endscript<br />
}<br />
</pre><br />
<br />
* Revision der logging rules: 3 Tage backlog für /var/log/syslog. Dump /etc/logrotate.d/rsyslog:<br />
<pre><br />
/var/log/syslog<br />
{<br />
rotate 3<br />
daily<br />
missingok<br />
notifempty<br />
delaycompress<br />
compress<br />
postrotate<br />
invoke-rc.d rsyslog rotate > /dev/null<br />
endscript<br />
}<br />
<br />
/var/log/mail.info<br />
/var/log/mail.warn<br />
/var/log/mail.err<br />
/var/log/mail.log<br />
/var/log/daemon.log<br />
/var/log/kern.log<br />
/var/log/auth.log<br />
/var/log/user.log<br />
/var/log/lpr.log<br />
/var/log/cron.log<br />
/var/log/debug<br />
/var/log/messages<br />
{<br />
rotate 4<br />
weekly<br />
missingok<br />
notifempty<br />
compress<br />
delaycompress<br />
sharedscripts<br />
postrotate<br />
invoke-rc.d rsyslog rotate > /dev/null<br />
endscript<br />
}<br />
</pre><br />
<br />
== 03.12.2015 ==<br />
* mrtg max range für fffauxvpn und bat0 angepasst<br />
* gre tunnel nach has2 hinzugefügt<br />
<br />
== 14.02.2016 ==<br />
* Freifunk DNS Konfiguration entsprechend https://wiki.freifunk-franken.de/w/DNS#Beispielhafte_Installation eingerichtet.<br />
<br />
== 15.03.2016 ==<br />
* Key von christiand entfernt. Ab sofort kein Login mehr möglich.<br />
* Home von Christiand gelöscht und Account gesperrt.<br />
<br />
== 15.05.2016 ==<br />
* kleev2 aus /etc/network/interfaces gelöscht, gre-Tunnel zu kleev2 entfernt<br />
* kleev2 aus dem Server-Monitoring (vnstat, mrtg) entfernt</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Server/fff-fra1/Log&diff=6600
Server/fff-fra1/Log
2016-05-15T16:45:22Z
<p>Green: /* 15.03.2016 */</p>
<hr />
<div>__NOTOC__<br />
<br />
== 08.10.15 ==<br />
* Passwort für fffranken geändert.<br />
* Passwort für root geändert.<br />
<br />
== 09.10.15 ==<br />
=== sudo installieren (als root) ===<br />
<code><br />
apt-get update<br />
<br />
apt-get install sudo<br />
</code><br />
<br />
=== Neuen User delpiN angelegt (als root) ===<br />
<code><br />
adduser delphin<br />
<br />
adduser delphin sudo<br />
<br />
nano /etc/sudoers<br />
</code><br />
<pre><br />
# User privilege specification<br />
root ALL=(ALL:ALL) ALL<br />
delphin ALL=(ALL:ALL) ALL<br />
</pre><br />
<br />
=== fail2ban installiert und eingerichtet ===<br />
<code><br />
sudo apt-get install fail2ban<br />
<br />
sudo nano /etc/fail2ban/jail.local<br />
<br />
sudo /etc/init.d/fail2ban restart<br />
</code><br />
<br />
=== SSH Port geändert ===<br />
Es sollte einen Port gewählt werden der nicht bereits vergeben ist (Liste vergebener Ports: ''more /etc/services'')<br />
<br />
<code><br />
sudo nano /etc/ssh/sshd_config<br />
</code><br />
<pre><br />
# What ports, IPs and protocols we listen for<br />
Port 8024<br />
</pre><br />
<br />
<code><br />
/etc/init.d/ssh restart<br />
</code><br />
<br />
=== SSH Login nur über Key erlauben ===<br />
<code><br />
sudo nano /etc/ssh/sshd_config<br />
</code><br />
<pre><br />
RSAAuthentification no<br />
AuthorizedKeysFile %h/.ssh/authorized_keys<br />
IgnoreUserKnowHosts yes<br />
ChallengeResponseAuthentication no<br />
PasswordAuthentication no<br />
</pre><br />
<br />
<code><br />
sudo /etc/init.d/ssh restart<br />
</code><br />
<br />
=== vnstat installiert ===<br />
<code><br />
sudo apt-get install vnstat<br />
</code><br />
<br />
=== mtr installiert ===<br />
<code><br />
sudo apt-get install mtr<br />
</code><br />
<br />
== 11.10.15 ==<br />
* 3x User hinzugefügt (mifritscher, christiand, green) (login via ssh key only)<br />
* 3 Usern sudo Rechte eingeräumt (/etc/sudoers)<br />
* sudo ohne erneute Passwordeingabe (sudo visudo; username ALL=(ALL) NOPASSWD: ALL)<br />
* screen installiert<br />
* dist-upgrade<br />
* BTAMAN compilieren<br />
* batctl compiliert<br />
* fastd installiert<br />
* kein OpenVPN<br />
* DHCP<br />
* bind9<br />
* wget https://mifritscher.de/austausch/olsrd/jessie/olsrd_0.6.8.1-1_amd64.deb<br />
* wget https://mifritscher.de/austausch/olsrd/jessie/olsrd-plugins_0.6.8.1-1_amd64.deb<br />
* dpkg -i olsrd-plugins_0.6.8.1-1_amd64.deb<br />
* dpkg -i olsrd_0.6.8.1-1_amd64.deb<br />
<br />
* Packete auf FTP kopiert:<br />
** http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd-plugins_0.6.8.1-1_amd64.deb<br />
** http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd_0.6.8.1-1_amd64.deb<br />
<br />
<code><br />
# device: bat0<br />
iface bat0 inet manual<br />
post-up ifconfig $IFACE up<br />
##Einschalten post-up:<br />
# IP des Gateways am B.A.T.M.A.N interface:<br />
post-up ip addr add 10.50.240.2/21 dev $IFACE<br />
# Regeln, wann die fff Routing-Tabelle benutzt werden soll: <br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.0.0.0/8 table fff<br />
post-up ip rule add to 10.0.0.0/8 table fff<br />
# Route in die Aux Hood:<br />
post-up ip route add 10.50.240.0/21 dev $IFACE table fff<br />
# Start des DHCP Servers:<br />
### post-up invoke-rc.d isc-dhcp-server restart<br />
<br />
##Ausschalten post-down:<br />
# Loeschen von oben definieren Routen, Regeln und Interface: <br />
post-down ip route del 10.50.240.0/21 dev $IFACE table fff<br />
post-down ip rule del from 10.0.0.0/8 table fff<br />
post-down ip rule del to 10.0.0.0/8 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ifconfig $IFACE down<br />
<br />
# VPN Verbindung in die Aux Hood<br />
iface fffauxVPN inet manual<br />
post-up batctl -m bat0 if add $IFACE<br />
post-up ifconfig $IFACE up<br />
post-up ifup bat0<br />
post-down ifdown bat0<br />
post-down ifconfig $IFACE down<br />
</code><br />
* Fastd Skript einfügen<br />
<code><br />
christiand@fff-fra1:~$ cat /etc/fastd/fff_aux_fastd.sh<br />
#!/bin/sh<br />
<br />
SERVERNAME="fff-fra1"<br />
<br />
hood="def"<br />
project="fffaux"<br />
port=10000<br />
<br />
SERVERNAME="$SERVERNAME.$hood"<br />
<br />
hostname=$SERVERNAME<br />
<br />
if [ ! -d /etc/fastd ]<br />
then<br />
mkdir /etc/fastd<br />
fi<br />
<br />
if [ ! -d /etc/fastd/$project.$hood ]<br />
then<br />
mkdir /etc/fastd/$project.$hood<br />
mkdir /etc/fastd/$project.$hood/peers<br />
<br />
#fastd config<br />
(<br />
echo "# Log warnings and errors to stderr"<br />
echo "log level error;"<br />
echo "# Log everything to a log file"<br />
echo "log to syslog as \"${project}${hood}\" level info;"<br />
echo "# Set the interface name"<br />
echo "interface \"${project}${hood}VPN\";"<br />
echo "# Support xsalsa20 and aes128 encryption methods, prefer xsalsa20"<br />
echo "#method \"xsalsa20-poly1305\";"<br />
echo "#method \"aes128-gcm\";"<br />
echo "method \"null\";"<br />
echo "# Bind to a fixed port, IPv4 only"<br />
echo "bind any:${port};"<br />
echo "# Secret key generated by \"fastd --generate-key\""<br />
echo "secret \"$(fastd --generate-key | grep -i Secret | awk '{print $2}')\";"<br />
echo "# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)"<br />
echo "# (see MTU selection documentation)"<br />
echo "mtu 1426;"<br />
echo "on up \"/etc/fastd/${project}.${hood}/up.sh\";"<br />
echo "on post-down \"/etc/fastd/${project}.${hood}/down.sh\";"<br />
echo "# Include peers from the directory 'peers'"<br />
echo "include peers from \"/etc/fastd/${project}.${hood}/peers\";"<br />
echo "secure handshakes no;"<br />
) >> "/etc/fastd/$project.$hood/$project.$hood.conf"<br />
<br />
#fastd-up<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifdown \$INTERFACE"<br />
) >> /etc/fastd/$project.$hood/down.sh<br />
<br />
chmod +x /etc/fastd/$project.$hood/down.sh<br />
<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifup \$INTERFACE" >> /etc/fastd/$project.$hood/up.sh<br />
) >> /etc/fastd/$project.$hood/up.sh<br />
chmod +x /etc/fastd/$project.$hood/up.sh<br />
fi<br />
<br />
pubkey=$(fastd -c /etc/fastd/$project.$hood/$project.$hood.conf --show-key --machine-readable)<br />
port=$(grep ^bind /etc/fastd/$project.$hood/$project.$hood.conf | cut -d: -f2 | cut -d\; -f1)<br />
<br />
# fire up<br />
if [ "$(/sbin/ifconfig -a | grep -i ethernet | grep ${project}${hood}VPN)" = "" ]<br />
then<br />
/bin/rm /var/run/fastd.$project.$hood.pid<br />
fastd -c /etc/fastd/$project.$hood/$project.$hood.conf -d --pid-file /var/run/fastd.$project.$hood.pid<br />
fi<br />
<br />
# register<br />
wget -T15 -q "http://keyserver.freifunk-franken.de/${project}/?name=$hostname&port=$port&key=$pubkey" -O /tmp/fastd_${project}.${hood}_output<br />
if [ "$?" != "0" ]<br />
then<br />
echo "Update failed"<br />
echo "Exiting, no clean up, no refresh"<br />
exit<br />
fi<br />
<br />
touch /tmp/fastd_${project}.${hood}_starting<br />
<br />
filenames=$(cat /tmp/fastd_${project}.${hood}_output| grep ^#### | sed -e 's/^####//' | sed -e 's/.conf//g')<br />
for file in $filenames<br />
do<br />
grep -A100 ^####$file.conf$ /tmp/fastd_${project}.${hood}_output | grep -v ^####$file.conf$ | grep -m1 ^### -B100 | grep -v ^### | sed 's/ float;/;/g' > "/etc/fastd/$project.$hood/peers/$file"<br />
echo 'float yes;' >> "/etc/fastd/$project.$hood/peers/$file"<br />
done<br />
<br />
#find old peers<br />
OLD=$(find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print)<br />
<br />
if [ -n "${OLD}" ] ; then<br />
echo "Lösche alte:"<br />
echo $OLD<br />
<br />
find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print | xargs /bin/rm /tmp/fastd_${project}.${hood}_starting<br />
fi<br />
<br />
#reload<br />
kill -HUP "$(cat /var/run/fastd.$project.$hood.pid)"<br />
<br />
exit 0<br />
</code><br />
* Hostname geändert<br />
* IP Forwarding aktiviert<br />
* Fastd Skript ausführbar (chmod +x /etc/fastd/fff_aux_fastd.sh)<br />
* fastd Script gestartet, interface Name angepasst<br />
dabei gab es Probleme, erst beim 2. Start des fastd Scripts kamen die Interface richtig hoch.<br />
* fastd Script in crontab und rc.local<br />
* dns / bind9 als caching nameserver (8.8.8.8, 10.50.240.1)<br />
* batman gw selection 1:1 aus anleitung<br />
* bat0 als interface dhcp-server<br />
* dhcp config:<br />
<code><br />
## Freifunk Franken <br />
option domain-name "fff.community"; <br />
option domain-name-servers 10.50.240.2; <br />
authoritative; <br />
## aux <br />
subnet 10.50.32.0 netmask 255.255.248.0 { # Netzwerk und Netzmaske der Aux<br />
range 10.50.242.0 10.50.243.255; # IP-Range die der DHCP-Server i<br />
option routers 10.50.240.2; # Default-Gateway, dass Clients <br />
option domain-name-servers 10.50.240.2; # Name-Server, die Clients mitge<br />
}<br />
</code><br />
* gre Tunnel nach kleeV2 und bbg / klappt noch nicht / erneuter test nach einrichten von olsr<br />
<br />
* olsr installiert. interfaces nach kleeV2, bbg<br />
* tunnel nach kleev2 funktioniert<br />
* Routing Tabelle wird über kleev2 ausgetauscht<br />
* DHCP Subnetz nach 10.50.240.0/21 korrigiert<br />
* Probleme mit dem KeyXchange -> Fix von Tim, fastd Neustart<br />
* Client bezieht keine IP, Batman zeigt keinen Hop zum mit aux-FW geflashten Router<br />
* WR841ND mit Beta der Aux-Firmware geflascht. Nach langer Fehlersuche funktioniert B.A.T.M.A.N auf Router und GW. Zugang auf Router schwierig -> Anschluss von Client port und WAN port an Heimrouter. Später: Selbstheilung ohne erkennbare Einwirkung.<br />
* DHCP manuell gestartet, aus irgendwelchen Gründen nicht bei automatisch bei reboot.<br />
* Masquerading auf dem GW aktiviert: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE. Eintrag in /etc/rc.local<br />
* Test: Umleiten des Traffic von kleev2 nach fra1, indem neue default route in kleev2 definiert wurde ("ip route add default via 10.50.252.48 table fff") -> Erfolgreich<br />
<br />
== 12.10.2015 ==<br />
* apache2 installiert<br />
* snpd und mrtg nach https://wiki.freifunk-franken.de/w/Portal:Netz/Statistiken eingerichtet. Abweichung: statt CPU.cfg system.mfg und kein eigener index.<br />
* apache2 index in /etc/apache2/sites-available/000-default.conf nach /var/www geändert.<br />
* robots.txt -> /var/www: No searchbot crawling<br />
* vnstat nach http://www.tecmint.com/vnstat-php-frontend-for-monitoring-network-bandwidth/ eingerichtet. Databases "vnstat -u -i INTERFACE" und php-Anzeige /var/www/vnstat/config.php für eth0, bat0, kleeV2, bbg, fffauxdefVPN<br />
* Kopie von dhcpd-pool und dhcp-statistics.sh nach /usr/local/bin, Eintrag von dhcp-statistics.sh in die crontab (alle 5 Minuten)<br />
* In Crontab -> Tägliches Löschen von /var/www/topology-*.dot Dateien, die älter als 2 Tage sind (find /var/www -name "topology-????-??-??-??-??-??.dot" -mtime +2 | xargs rm -f)<br />
* Installation von phplot entsprechend http://www.phplot.com/phplotdocs/install.html<br />
* Webseite mit Monitoring Tools und Impressum hinzugefügt<br />
* ''curl'' installiert<br />
<br />
== 13.10.2015 ==<br />
* sudo user "dpaufler" angelegt. Key eingetragen.<br />
* node.js installiert:<br />
<code><br />
apt-get install npm<br />
<br />
sudo npm cache clean -f<br />
<br />
sudo npm install -g n<br />
<br />
sudo n stable<br />
<br />
sudo npm install npm -g<br />
</code><br />
<br />
== 14.10.2015 ==<br />
* [http://www.olsr.org/?q=jsoninfo_plugin OLSR_JsonInfo_Plugin] aktiviert. (Beispiel: http://84.200.64.42:9090/interfaces)<br />
<br />
== 17.10.2015 ==<br />
* Logrotate angepasst: 3 Tage backlogs ist Standard (/etc/logrotate.conf)<br />
* DHCP Ausgabe deaktiviert. Auszug aus /etc/log/rsyslogd.conf:<br />
<pre><br />
# /etc/rsyslog.conf Configuration file for rsyslog.<br />
#<br />
# For more information see<br />
# /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html<br />
<br />
<br />
##############<br />
#### DHCP ####<br />
##############<br />
#:programname, isequal, "dhcpd" /var/log/dhcpd.log<br />
:programname, isequal, "dhcpd" /dev/null<br />
:programname, isequal, "dhcpd" ~<br />
.<br />
.<br />
.<br />
</pre><br />
* Logrotate angepasst: 1 Tag backlog für /var/log/dhcpd.log (/etc/logrotate.conf)<br />
* Um logrotate von /var/lib/dhcp/dhcpd.leases zu ermöglichen, 5-minütigen cron-job eingerichtet, der folgendes ausführt: "chown -R dhcpd:dhcpd /var/lib/dhcp" (siehe https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1186662)<br />
<br />
== 19.10.2015 ==<br />
* iperf installiert<br />
* Logging-Regeln angepasst:<br />
** Verwerfen aller Logs von dhcpd. dump /etc/rsyslogd.conf<br />
<pre><br />
# /etc/rsyslog.conf Configuration file for rsyslog.<br />
#<br />
# For more information see<br />
# /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html<br />
<br />
<br />
##############<br />
#### DHCP ####<br />
##############<br />
#:programname, isequal, "dhcpd" /var/log/dhcpd.log<br />
:programname, isequal, "dhcpd" /dev/null<br />
:programname, isequal, "dhcpd" ~<br />
<br />
<br />
#################<br />
#### MODULES ####<br />
#################<br />
<br />
$ModLoad imuxsock # provides support for local system logging<br />
$ModLoad imklog # provides kernel logging support<br />
#$ModLoad immark # provides --MARK-- message capability<br />
<br />
# provides UDP syslog reception<br />
#$ModLoad imudp<br />
#$UDPServerRun 514<br />
<br />
# provides TCP syslog reception<br />
#$ModLoad imtcp<br />
#$InputTCPServerRun 514<br />
<br />
<br />
###########################<br />
#### GLOBAL DIRECTIVES ####<br />
###########################<br />
<br />
#<br />
# Use traditional timestamp format.<br />
# To enable high precision timestamps, comment out the following line.<br />
#<br />
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat<br />
<br />
#<br />
# Set the default permissions for all log files.<br />
#<br />
$FileOwner root<br />
$FileGroup adm<br />
$FileCreateMode 0640<br />
$DirCreateMode 0755<br />
$Umask 0022<br />
<br />
#<br />
# Where to place spool and state files<br />
#<br />
$WorkDirectory /var/spool/rsyslog<br />
<br />
#<br />
# Include all config files in /etc/rsyslog.d/<br />
#<br />
$IncludeConfig /etc/rsyslog.d/*.conf<br />
<br />
<br />
###############<br />
#### RULES ####<br />
###############<br />
<br />
#<br />
# First some standard log files. Log by facility.<br />
#<br />
auth,authpriv.* /var/log/auth.log<br />
*.*;auth,authpriv.none -/var/log/syslog<br />
#cron.* /var/log/cron.log<br />
daemon.* -/var/log/daemon.log<br />
kern.* -/var/log/kern.log<br />
lpr.* -/var/log/lpr.log<br />
mail.* -/var/log/mail.log<br />
user.* -/var/log/user.log<br />
<br />
#<br />
# Logging for the mail system. Split it up so that<br />
# it is easy to write scripts to parse these files.<br />
#<br />
mail.info -/var/log/mail.info<br />
mail.warn -/var/log/mail.warn<br />
mail.err /var/log/mail.err<br />
<br />
#<br />
# Logging for INN news system.<br />
#<br />
news.crit /var/log/news/news.crit<br />
news.err /var/log/news/news.err<br />
news.notice -/var/log/news/news.notice<br />
<br />
#<br />
# Some "catch-all" log files.<br />
#<br />
*.=debug;\<br />
auth,authpriv.none;\<br />
news.none;mail.none -/var/log/debug<br />
*.=info;*.=notice;*.=warn;\<br />
auth,authpriv.none;\<br />
cron,daemon.none;\<br />
mail,news.none -/var/log/messages<br />
<br />
#<br />
# Emergencies are sent to everybody logged in.<br />
#<br />
*.emerg :omusrmsg:*<br />
<br />
#<br />
# I like to have messages displayed on the console, but only on a virtual<br />
# console I usually leave idle.<br />
#<br />
#daemon,mail.*;\<br />
# news.=crit;news.=err;news.=notice;\<br />
# *.=debug;*.=info;\<br />
# *.=notice;*.=warn /dev/tty8<br />
<br />
# The named pipe /dev/xconsole is for the `xconsole' utility. To use it,<br />
# you must invoke `xconsole' with the `-file' option:<br />
# <br />
# $ xconsole -file /dev/xconsole [...]<br />
#<br />
# NOTE: adjust the list below, or you'll go crazy if you have a reasonably<br />
# busy site..<br />
#<br />
daemon.*;mail.*;\<br />
news.err;\<br />
*.=debug;*.=info;\<br />
*.=notice;*.=warn |/dev/xconsole<br />
</pre><br />
** Generell 3 Tage backlogs:<br />
<pre><br />
# see "man logrotate" for details<br />
# rotate log files daily<br />
daily<br />
<br />
# keep 3 days worth of backlogs<br />
rotate 3<br />
<br />
# create new (empty) log files after rotating old ones<br />
create<br />
<br />
# uncomment this if you want your log files compressed<br />
compress<br />
<br />
# packages drop log rotation information into this directory<br />
include /etc/logrotate.d<br />
<br />
# no packages own wtmp, or btmp -- we'll rotate them here<br />
/var/log/wtmp {<br />
missingok<br />
monthly<br />
create 0664 root utmp<br />
rotate 1<br />
}<br />
<br />
/var/log/btmp {<br />
missingok<br />
monthly<br />
create 0660 root utmp<br />
rotate 1<br />
}<br />
<br />
# system-specific logs may be configured here<br />
<br />
# system-specific logs may be configured here<br />
/var/log/dhcpd.log {<br />
rotate 1<br />
daily<br />
compress<br />
}<br />
</pre><br />
** Flush des DHCP lease files um 3.31 Uhr morgens. Dump crontab:<br />
<pre><br />
# m h dom mon dow command<br />
*/10 * * * * sh /etc/fastd/fff_aux_fastd.sh<br />
*/5 * * * * perl /etc/olsrd/dotDraw.pl > /dev/null 2>&1<br />
*/1 * * * * env LANG=C /usr/bin/mrtg /etc/mrtg/system.cfg > /dev/null 2>&1<br />
*/1 * * * * env LANG=C /usr/bin/mrtg /etc/mrtg/traffic.cfg > /dev/null 2>&1<br />
*/5 * * * * /usr/bin/vnstat -u >/dev/null 2>&1<br />
*/5 * * * * sudo dhcp-statistics.sh<br />
45 2 * * * find /var/www/topology/. -name "topology-????-??-??-??-??-??.dot" -mtime +1 | xargs rm -f<br />
#*/5 * * * * sudo chown -R dhcpd:dhcpd /var/lib/dhcp<br />
31 3 * * * sudo flush_dhcp.sh<br />
</pre><br />
** Flush des DHCP lease files um 3.31 Uhr morgens. Dump flush_dhcp.sh:<br />
<pre><br />
#!/bin/bash<br />
leasefile="/var/lib/dhcp/dhcpd.leases"<br />
<br />
/etc/init.d/isc-dhcp-server stop<br />
rm "$leasefile"<br />
rm "$leasefile~"<br />
touch "$leasefile"<br />
echo "" > "$leasefile"<br />
/etc/init.d/isc-dhcp-server start<br />
</pre><br />
<br />
== 22.10.2015 ==<br />
* Umstellung des IP-Bereichs auf 84.200.64.40/29<br />
<br />
== 23.10.2015 ==<br />
* Christohper Mäuer (von dotmanaged) User angelegt<br />
* Eintrag in der /etc/rc.local eingefügt:<br />
<pre><br />
#dhcp-server starten - geht beim Systemstart nicht, da dann das entsprechende Interface noch nicht da ist<br />
(sleep 30; /etc/init.d/isc-dhcp-server start) &<br />
</pre><br />
<br />
<br />
== 31.10.2015 ==<br />
* Revision der Logging-Rules: Dedicated log-file für snmpd<br />
* Auszug rsyslogd.conf:<br />
<pre><br />
###############<br />
#### SNMPD ####<br />
###############<br />
# Redirect snmpd<br />
:programname, isequal, "snmpd" /var/log/snmpd.log<br />
:programname, isequal, "snmpd" ~<br />
</pre><br />
<br />
* Auszug logrotate.conf:<br />
<pre><br />
/var/log/snmpd.log {<br />
rotate 3<br />
daily<br />
compress<br />
}<br />
</pre><br />
<br />
* Revision der logging rules: 3 Tage backlog für apache2. Dump /etc/logrotate.d/apache2:<br />
<pre><br />
/var/log/apache2/*.log {<br />
daily<br />
missingok<br />
rotate 3<br />
compress<br />
delaycompress<br />
notifempty<br />
create 640 root adm<br />
sharedscripts<br />
postrotate<br />
if /etc/init.d/apache2 status > /dev/null ; then \<br />
/etc/init.d/apache2 reload > /dev/null; \<br />
fi;<br />
endscript<br />
prerotate<br />
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \<br />
run-parts /etc/logrotate.d/httpd-prerotate; \<br />
fi; \<br />
endscript<br />
}<br />
</pre><br />
<br />
* Revision der logging rules: 3 Tage backlog für /var/log/syslog. Dump /etc/logrotate.d/rsyslog:<br />
<pre><br />
/var/log/syslog<br />
{<br />
rotate 3<br />
daily<br />
missingok<br />
notifempty<br />
delaycompress<br />
compress<br />
postrotate<br />
invoke-rc.d rsyslog rotate > /dev/null<br />
endscript<br />
}<br />
<br />
/var/log/mail.info<br />
/var/log/mail.warn<br />
/var/log/mail.err<br />
/var/log/mail.log<br />
/var/log/daemon.log<br />
/var/log/kern.log<br />
/var/log/auth.log<br />
/var/log/user.log<br />
/var/log/lpr.log<br />
/var/log/cron.log<br />
/var/log/debug<br />
/var/log/messages<br />
{<br />
rotate 4<br />
weekly<br />
missingok<br />
notifempty<br />
compress<br />
delaycompress<br />
sharedscripts<br />
postrotate<br />
invoke-rc.d rsyslog rotate > /dev/null<br />
endscript<br />
}<br />
</pre><br />
<br />
== 03.12.2015 ==<br />
* mrtg max range für fffauxvpn und bat0 angepasst<br />
* gre tunnel nach has2 hinzugefügt<br />
<br />
== 14.02.2016 ==<br />
* Freifunk DNS Konfiguration entsprechend https://wiki.freifunk-franken.de/w/DNS#Beispielhafte_Installation eingerichtet.<br />
<br />
== 15.03.2016 ==<br />
* Key von christiand entfernt. Ab sofort kein Login mehr möglich.<br />
* Home von Christiand gelöscht und Account gesperrt.<br />
<br />
== 15.05.2016 ==<br />
* kleev2 aus /etc/network/interfaces gelöscht, gre-Tunnel zu kleev2 entfernt<br />
* kleev2 aus dem Server-Monitoring entfernt</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Server/fff-fra1&diff=6599
Server/fff-fra1
2016-05-15T16:38:49Z
<p>Green: /* Status */</p>
<hr />
<div>__NOTOC__<br />
<br />
= Gateway Server fff-fra1 =<br />
<br />
'''<font style="color:green">Status: online</font>'''<br />
<br />
== Status ==<br />
<br />
Zur Nachvollziebarkeit der Server-Einrichtung wird in ein [[Server/fff-fra1/Log|detailiertes Log]] geführt.<br />
<br />
* 25.09.15: Anfrage nach Untersützung für Flüchtlingsunterkünfte über [https://twitter.com/FreifunkFranken/status/647319580168310784 Twitter]<br />
* 25.09.15: Angebot von dotManaged für einen Server mit bis zu 20 TB/Monat Traffic kostenlos.<br />
* 07.10.15: Vertrag ist vom Förderverein unterschrieben und wurde von delphiN an dotManaged weitergeleitet.<br />
* 08.10.15: delphiN hat Zugangsdaten bekommen (Passwörter geändert)<br />
* 09.10.15: Grundeinrichtung des Systems.<br />
* 11.10.15: Plaungstreffen und einrichtung als Layers2-Gateway.<br />
* 13.10.15: Testweise an Nürnberger Hood angeschlossen um zu testen.<br />
* 17.10.15: ca. 17 Uhr Speedtest<br />
* 18.10.15: ca. 18 Uhr Ein erster unbekannter Knoten geht ans Netz.<br />
* 22.10.15: Umstellung des IP-Bereichs<br />
* 24.10.15: RAM-Menge wurde vom Hoster gefixt (jetzt sind es 4 GB)<br />
* 22.12.15: November 2015: ca. 10TB pro Monat<br />
* 31.12.15: Ende Dez'15: ca. 1 TB am Tag, Tendenz steigend<br />
* 12.01.16: Hoster hat Speed-Limit auf 64Mbit/s eingerichtet um Volumensgrenze nicht zu überschreiten.<br />
* 04.03.16: Traffic-Limit wurde auf 50TB/Monat erhöht. Danke :-)<br />
* 15.03.16: Er kann nun für Freifunk allgemein verwendet werden. Auch dafür Danke :-)<br />
* 15.03.16: ChristianD hat sich aus der Administration zurückgezogen<br />
* Mai 2016: Hoster hat Speed-Limit auf 48Mbit/s eingerichtet<br />
* 15.05.16: Hoster hat den Vertrag regulär gekündigt und versucht zusätzlich ein vorzeitiges Sonderkündigungsrecht durchzusetzen<br />
<br />
== Monitoring ==<br />
* http://fff-fra1.fff.community/<br />
** [https://www.dotmanaged.eu/rechenzentrum/weathermap/ Network-Weathermap dotManaged]<br />
** [http://84.200.64.42 Übersicht]<br />
** [http://84.200.64.42:8080/ OLSR Status]<br />
** [http://84.200.64.42:8083/ Realtime Server Monitor]<br />
<br />
== Ansprechpartner ==<br />
* '''Allgemein Fragen''': fragen ET freifunk-franken.de<br />
* '''Abuse''': abuse ET freifunk-franken.de<br />
* '''Admins''':<br />
** [[Benutzer:delphiN|delphiN]] (Admin-C)<br />
** [[Benutzer:mifritscher|mifritscher]] (Tech-C)<br />
** [[Benutzer:green|green]] (Monitoring, Wartung, usw.)<br />
** [http://wiki.freifunk.net/Benutzer:DanielP DanielP] (Admin vom Foerderverein Freie Netzwerke e.V.)<br />
* '''Sonstige User''':<br />
** [[Benutzer:ChristopherMaeuer|ChristopherMaeuer]] (Ansprechpartner bei dotManaged)<br />
<br />
== Details ==<br />
<br />
* '''Type''': KVM Server<br />
* '''Verwendungszweck''': Internet-Gateway Server<br />
* '''Provider''': [https://www.dotmanaged.eu/ dotManaged]<br />
* '''Standort''': Frankfurt [https://www.accelerated.de/de/rechenzentrum]<br />
* '''Eigentümer''': Freie Netze e.V.<br />
* '''Kosten''': Spende von dotManaged gegen Spendenquittung<br />
<br />
* '''Technische Daten''':<br />
** IP-Bereich:<br />
*** 84.200.64.42 (84.200.64.40/29)<br />
** OS: Debian GNU/Linux 8.2 (jessie)<br />
** CPU: 4 x Intel Xeon E312xx (Sandy Bridge) 2.5GHz; vCore<br />
** RAM: 4 GB DDR3-1333 MHz ECC Registered<br />
** HDD: 10 GB HDD Raid-10 w/ 4x 2 TB Western Digital SE<br />
** NIC: VirtIO zu Intel NIC mit maximal 1 GBit/s<br />
<br />
== RIPE Einträge ==<br />
<br />
<pre><br />
inetnum: 84.200.64.40 - 84.200.64.47<br />
netname: DE-FREIFUNK-FRANKEN-01<br />
descr: Foerderverein Freie Netzwerke e.V.<br />
country: DE<br />
admin-c: AW5350-RIPE<br />
tech-c: TG5171-RIPE<br />
org: ORG-FFNE2-RIPE<br />
status: ASSIGNED PA<br />
mnt-by: MNT-WEESLY<br />
created: 2015-10-05T09:17:16Z<br />
last-modified: 2015-10-09T17:01:10Z<br />
source: RIPE<br />
</pre><br />
<br />
=== [https://apps.db.ripe.net/search/lookup.html?source=ripe&key=AR33715-RIPE&type=role ORGANISATION] ===<br />
<pre><br />
organisation: ORG-FFNE2-RIPE<br />
org-name: Foerderverein Freie Netzwerke e.V.<br />
org-type: OTHER<br />
address: Foerderverein Freie Netzwerke e.V.<br />
address: Freifunk Franken<br />
address: c/o Rabener - Rau<br />
address: Stephanstr. 10<br />
address: D-10559 Berlin<br />
abuse-c: AR33715-RIPE<br />
mnt-ref: MNT-WEESLY<br />
mnt-by: MNT-WEESLY<br />
created: 2015-10-05T09:12:49Z<br />
last-modified: 2015-10-07T19:24:32Z<br />
source: RIPE # Filtered<br />
</pre><br />
<br />
=== [https://apps.db.ripe.net/search/lookup.html?source=ripe&key=AW5350-RIPE&type=person ADMIN-C] === <br />
<pre><br />
person: Alexander Wunschik<br />
address: Foerderverein Freie Netzwerke e.V.<br />
address: Freifunk Franken<br />
address: c/o Rabener - Rau<br />
address: Stephanstr. 10<br />
address: D-10559 Berlin<br />
phone: +49 (911) 495205200<br />
abuse-mailbox: abuse@freifunk-franken.de<br />
nic-hdl: AW5350-RIPE<br />
mnt-by: MNT-WEESLY<br />
created: 2015-10-09T16:59:51Z<br />
last-modified: 2015-10-09T16:59:51Z<br />
source: RIPE # Filtered<br />
</pre><br />
<br />
=== [https://apps.db.ripe.net/search/lookup.html?source=ripe&key=TG5171-RIPE&type=person TECH-C] === <br />
<pre><br />
person: Michael Fritscher<br />
address: Foerderverein Freie Netzwerke e.V.<br />
address: Freifunk Franken<br />
address: c/o Rabener - Rau<br />
address: Stephanstr. 10<br />
address: D-10559 Berlin<br />
phone: +49 700 23023023<br />
abuse-mailbox: abuse@freifunk-franken.de<br />
nic-hdl: TG5171-RIPE<br />
mnt-by: MNT-WEESLY<br />
created: 2015-10-09T17:00:49Z<br />
last-modified: 2015-10-09T17:00:49Z<br />
source: RIPE # Filtered<br />
</pre><br />
<br />
[[Kategorie:Technik]]<br />
[[Kategorie:Server]]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Portal:Netz&diff=6598
Portal:Netz
2016-05-15T16:31:13Z
<p>Green: /* Liste der Subnetze */</p>
<hr />
<div>== Das Netz ==<br />
Eine Karte der aktiven Router gibt es [https://monitoring.freifunk-franken.de/map].<br />
<br />
Eine Karte der Hoods ist [http://keyserver.freifunk-franken.de/fff/voronoimap.php hier] zu finden.<br />
<br />
Die [https://monitoring.freifunk-franken.de/routers Liste der Router] kann dank Monitoring immer live verfolgt werden. Infos über die Schreibweise (z.B. "/20") gibt es in der [http://de.wikipedia.org/wiki/CIDR Wikipedia].<br />
<br />
=== Gateway ===<br />
Erste Versuche einer sinnvollen Aufteilung von Gateways. Erweiterungen und Verbesserungen sind jederzeit erwünscht. [https://pad.freifunk.net/p/Gatewayaufteilung-Franken Zum Pad]<br />
<br />
== IP-Netz ==<br />
Mit der Netz-Umstellung vom 22.03.2014 haben wir nicht mehr länger ein großes [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_2_.E2.80.93_Sicherungsschicht_.28Data_Link_Layer.29 Layer-II-Netz], welches durch das [https://de.wikipedia.org/wiki/B.A.T.M.A.N. B.A.T.M.A.N. advanced]-Protokoll geroutet wird. Seitdem gibt es mehrere [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_3_.E2.80.93_Vermittlungsschicht_.28Network_Layer.29 Layer-III-Netze] (Hoods). Ein Layer-III-Netz entsteht grundsätzlich, indem hier ein Subnetz eingetragen wird. Wie dabei genau vorgegangen wird, steht in [[HoodVerwaltung]].<br />
Für jedes Subnetz muss separat abgewogen werden, wie groß es werden wird und wo es dann in die bestehenden Subnetze am besten eingegliedert werden kann.<br />
<br />
==== DHCP ====<br />
[[Datei:Hoods.png|200px|thumb|right|Vorschlag für die Hood-Organisation]]<br />
Damit simple Clients das neue Subnetz nutzen können, muss ein eigener DHCP-Server pro Subnetz bereit gestellt werden. Es macht dabei häufig Sinn, das Subnetz in IP-Bereiche aufzuteilen, die von mehreren DHCP-Servern verteilt werden. Ein zweiter DHCP-Server ermöglicht zum einen eine Lastverteilung, zum anderen erhöht sich die Ausfallsicherheit. Der DHCP-Server muss den Clients ein Default-Gateway und mindestens einen DNS-Server zuweisen. Da das Default-Gateway ebenfalls innerhalb des Subnetzes liegen muss, bietet es sich an, den selben Server, auf dem das DHCP läuft, zu nutzen.<br />
<br />
==== OLSR-Router ====<br />
Das Subnetz muss anschließend an das vorhandene Freifunknetz angeschlossen werden. Dazu muss eine Verbindung zu einem bestehenden OLSR-Router aufgebaut werden. Dies kann eine VPN-Verbindung, aber auch eine Wifi-Verbindung sein und muss individuell zwischen den zwei Parteien ausgehandelt werden. Es kann sinnvoll sein, Verbindungen zu mehr als einem OLSR-Router zu haben. Sobald der eigene Router an das OLSR-Netz angebunden ist, ist er selbst ein OLSR-Router.<br />
<br />
An den eigenen OLSR-Router können nun Accesspoints angeschlossen werden. Dies kann per VPN, WLAN, Kabel oder anderweitig geschehen. Es ist auch möglich, den Accesspoint selbst als OLSR-Router anzubinden. Auch diese Konfiguration ist individuell zu klären. Ein Accesspoint kann ein (oder mehrere) einfacher Wifi-AP oder auch ein Array von mehreren B.A.T.M.A.N.-Knoten sein. Es sollte vermieden werden, dass sich Subnetze vermischen. Dies würde immer dann passieren, wenn zwei Layer-II-Netze, die eigentlich unterschiedliche Subnetze verteilen, verbunden werden. Besonders beim B.A.T.M.A.N.-Protokoll besteht hier leicht diese Gefahr; daher sollte für jedes Subnetz eine eigene BSSID und ESSID gewählt werden.<br />
<br />
==== Aus Routersicht ====<br />
Nur Router in einer Hood können sich per B.A.T.M.A.N. advanced vermaschen, sowohl per VPN, also auch per WLAN. Daher müssen Router die räumlich nahe beieinander stehen auch in derselben Hood sein. Durch das Vermaschen des Netzes wird allerdings auch Verwaltungs-Verkehr erzeugt (Overhead). Je größer die Hood, desto größer der Overhead.<br />
<br />
Eine Verbindung zwischen Routern in unterschiedlichen Hoods ist per IP (OSI Schicht 3) möglich.<br />
<br />
Wenn im Netmon kein Standort eingegeben wurde, dann landet der Router in der Dafault-Hood.<br />
<br />
==== Monitoring (Netmon) ====<br />
Aktuell können sich Knoten nur über ein IPv6-Link-Local-Interface beim Netmon anmelden und Netmon kann die Knoten nur über eine IPv6-Link-Local-Adresse abfragen. Hier muss ein neuer Mechanismus gefunden werden, der es ermöglicht, die Knoten über Subnetze hinweg anzusprechen.<br />
<br />
Als Workaround ist es möglich, über einen Layer-II-Tunnel zum Netmon-Server das Subnetz an das Netmon anzubinden. Auf dem Netmon-Server werden alle Subnetze in einem Bridge-Interface zusammengefasst, welches keine Pakete weiterleiten kann.<br />
<br />
==== Wireless-LAN ====<br />
Wir haben uns auf folgende WLAN-Parameter verständigt:<br />
'''ESSID: franken.freifunk.net'''. Kanal 1.<br />
<br />
== Liste der Subnetze ==<br />
{|<br />
! !! Bereich !! Bereitgestellt durch<br />
|-<br />
! 10.50.0.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.0.1 – 10.50.15.254</font> || <br />
|-<br />
! 10.50.16.0/20 || Default Hood ||<br />
|-<br />
| || 10.50.16.1 – 10.50.17.255 || Statische Adressen<br />
|-<br />
| || 10.50.18.0 – 10.50.19.255 || --<br />
|-<br />
| || 10.50.20.0 – 10.50.21.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey">10.50.22.0 – 10.50.23.254 </font> || <br />
|-<br />
| || <font color="grey">10.50.24.0 – 10.50.31.254 </font> || <br />
|-<br />
! 10.50.32.0/21 || Fürth Hood ||<br />
|-<br />
| || 10.50.32.1 – 10.50.32.255 || Statische Adressen<br />
|-<br />
| || 10.50.33.0 – 10.50.34.255 || [[fff-nue2|fff-nue2-gw1]]<br />
|-<br />
| || 10.50.35.0 – 10.50.36.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey"> 10.50.37.0 – 10.50.37.255 </font> || --<br />
|-<br />
| || 10.50.38.0 – 10.50.39.254 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.40.0/21 || Nürnberg Hood ||<br />
|-<br />
| || 10.50.40.1 – 10.50.40.255 || Statische Adressen<br />
|-<br />
| || 10.50.41.0 – 10.50.42.255 || [[Server#FFF-GW-M1|FFF-GW-M1]]<br />
|-<br />
| || <font color="grey"> 10.50.43.0 - 10.50.43.255 </font> || <br />
|-<br />
| || 10.50.44.0 – 10.50.44.255 || (umgezogen) [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| ||10.50.45.0 – 10.50.46.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.47.0 – 10.50.47.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.48.0/21 || Ansbach Hood ||<br />
|-<br />
| || 10.50.48.1 – 10.50.48.255 || Statische Adressen<br />
|-<br />
| || 10.50.49.0 – 10.50.50.255 || <br />
|-<br />
| || 10.50.51.0 – 10.50.52.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.53.0 – 10.50.54.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| || <font color="grey">10.50.55.0 – 10.50.55.254</font> || <br />
|-<br />
! 10.50.56.0/22 || Hassberge Hood ||<br />
|-<br />
| || 10.50.56.1 – 10.50.56.255 || Statische Adressen<br />
|-<br />
| || 10.50.57.0 – 10.50.57.255 || [[Server#fff-has3|fff-has3]]<br />
|-<br />
| || 10.50.58.0 – 10.50.58.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.59.0 – 10.50.59.254 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
! 10.50.60.0/22 || HassbergeSued Hood ||<br />
|-<br />
| || 10.50.60.1 – 10.50.60.255 || Statische Adressen<br />
|-<br />
| || 10.50.61.0 – 10.50.61.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
| || 10.50.62.0 – 10.50.62.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.63.0 – 10.50.63.254 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
! 10.50.64.0/21 || Erlangen Hood ||<br />
|-<br />
| || 10.50.64.1 – 10.50.64.255 || Statische Adressen<br />
|-<br />
| || 10.50.65.0 – 10.50.66.255 || [[Server#fff-gw-kwadro|fff-gw-kwadro]]<br />
|-<br />
| || 10.50.67.0 – 10.50.68.255 || free<br />
|-<br />
| || 10.50.69.0 – 10.50.71.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.72.0/21 || Würzburg Hood ||<br />
|-<br />
| || 10.50.72.1 – 10.50.72.255 || Statische Adressen<br />
|-<br />
| || <font color="grey"> 10.50.73.0 – 10.50.74.255 </font>|| <br />
|-<br />
| || 10.50.75.0 – 10.50.76.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.77.0 – 10.50.78.255 || [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || 10.50.79.0 – 10.50.79.254 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
! 10.50.80.0/21 || BGL ||<br />
|-<br />
| || 10.50.80.1 – 10.50.80.255 || Statische Adressen<br />
|-<br />
| || 10.50.81.0 – 10.50.82.255 || [[Server#watzmann|watzmann]]<br />
|-<br />
| || 10.50.83.0 – 10.50.84.255 || [[Server#staufen|staufen]]<br />
|-<br />
! 10.50.88.0/21 || NbgLand Hood ||<br />
|-<br />
| || 10.50.88.1 – 10.50.88.255 || Statische Adressen<br />
|-<br />
| || 10.50.89.0 – 10.50.89.255 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| || 10.50.90.0 - 10.50.91.255 || fff-gw-cdnbgland2 (Testbetrieb)<br />
|-<br />
| || <font color="grey">10.50.92.0 - 10.50.93.255</font> || <br />
|-<br />
| || 10.50.94.0 – 10.50.95.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.96.0/21 || Aschaffenburg Hood ||<br />
|-<br />
| || 10.50.96.1 – 10.50.96.255 || Statische Adressen<br />
|-<br />
| || 10.50.97.1 – 10.50.97.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
! 10.50.104.0/21 || Hof Hood ||<br />
|-<br />
| || 10.50.104.1 – 10.50.104.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.105.0 - 10.50.106.255</font> || free<br />
|-<br />
| || 10.50.107.0 – 10.50.107.255 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
| || 10.50.108.0 - 10.50.109.255 || fff-fr1-arm<br />
|-<br />
| || 10.50.110.1 - 10.50.111.254 || fff-gw-cdhof1<br />
|-<br />
! 10.50.112.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.112.1 – 10.50.119.254</font> || <br />
|-<br />
! 10.50.120.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.120.1 – 10.50.127.254</font> || <br />
|-<br />
! 10.50.128.0/24 || Test von Casandro ||<br />
|-<br />
| || 10.50.128.20 – 10.50.128.200 || 10.50.128.1<br />
|-<br />
! 10.50.129.0/24 || free ||<br />
|-<br />
| || 10.50.129.0 || free<br />
|-<br />
! 10.50.130.0/23 || Hardhöhe ||<br />
|-<br />
| || 10.50.130.1 - 10.50.130.255 || Statische Adressen<br />
|-<br />
| || 10.50.131.0 – 10.50.131.127 || Gateway Hochhaus<br />
|-<br />
! 10.50.132.0/22 || FabLabNbg Hood ||<br />
|-<br />
| || 10.50.132.1 - 10.50.132.255 || Statische Adressen<br />
|-<br />
| || 10.50.133.0 – 10.50.133.255 || FabLabNbgGW<br />
|-<br />
| || 10.50.134.0 - 10.50.135.254 || frei<br />
|-<br />
! 10.50.136.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.136.1 – 10.50.143.254</font> || <br />
|-<br />
! 10.50.144.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.144.1 – 10.50.159.254</font> || <br />
|-<br />
! 10.50.160.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.160.1 – 10.50.191.254</font> || <br />
|-<br />
! 10.50.192.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.192.1 – 10.50.223.254</font> || <br />
|-<br />
! 10.50.224.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.224.1 – 10.50.239.254</font> || <br />
|-<br />
! 10.50.240.0/21 || fffaux ||<br />
|-<br />
| || 10.50.240.1 – 10.50.240.255 || Statische Adressen<br />
|-<br />
| || 10.50.241.0 – 10.50.241.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.242.0 – 10.50.243.255 || [[Server#fff-fra1|fff-fra1]]<br />
|-<br />
| || 10.50.244.0 – 10.50.244.127 || Testinstallation Busch (Flo)<br />
|-<br />
| || <font color="grey"> 10.50.244.128 - 10.50.245.255 </font> || | <font color="grey"> (free) </font><br />
|-<br />
| || 10.50.246.0 - 10.50.247.254 || fff-gw-cdaux2<br />
|-<br />
<br />
! 10.50.248.0/22 || free ||<br />
|-<br />
| || 10.50.248.1 – 10.50.248.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.249.0 - 10.50.251.254</font> || <br />
|-<br />
! 10.50.252.0/22 || TUNNEL ||<br />
|-<br />
| || 10.50.252.0 fff_ro1 || 10.50.252.1 nue1 || <br />
|-<br />
| || 10.50.252.2 fff_ro1 || 10.50.252.3 watzmann || <br />
|-<br />
| || 10.50.252.4 fff_ro1 || 10.50.252.5 staufen || <br />
|-<br />
| || 10.50.252.6 fff_ro1 || 10.50.252.7 has2 || <br />
|-<br />
| || 10.50.252.8 fff_ro1 || 10.50.252.9 has || <br />
|-<br />
| || 10.50.252.10 ro1 || 10.50.252.11 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.12 fff-has2 || 10.50.252.13 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.14 fff-gw-m1 || 10.50.252.15 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || <font color="grey"> 10.50.252.16 (free) </font>|| 10.50.252.17 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || <font color="grey"> 10.50.252.18 (free)</font> || 10.50.252.19 nue1 ||<br />
|-<br />
| || 10.50.252.20 <font color="grey"> (free) </font> || 10.50.252.21 ro1 ||<br />
|-<br />
| || 10.50.252.22 fff-gw-yaga || 10.50.252.23 fff-wue1 ||<br />
|-<br />
| || 10.50.252.24 fff-gw-m1 || 10.50.252.25 fff-has2 ||<br />
|-<br />
| || 10.50.252.26 fff-gw-m1 || 10.50.252.27 fff-wue1 ||<br />
|-<br />
| || 10.50.252.28 fff-bbg || 10.50.252.29 fff-nue1 ||<br />
|-<br />
| || 10.50.252.30 fff-bbg || 10.50.252.31 fff-ro1 ||<br />
|-<br />
| || 10.50.252.32 fff-bbg || 10.50.252.33 fff-has2 ||<br />
|-<br />
| || 10.50.252.34 fff-bbg || <font color="grey"> 10.50.252.35 (free) </font> ||<br />
|-<br />
| || 10.50.252.36 fff-wue1 || 10.50.252.37 fff-bbg ||<br />
|-<br />
| || 10.50.252.38 fff-gw-m1 || 10.50.252.39 ro1 ||<br />
|-<br />
| || 10.50.252.40 fff-gw-yaga || 10.50.252.41 ro1 ||<br />
|-<br />
| || 10.50.252.42 fff-gw-yaga || 10.50.252.43 nue1 ||<br />
|-<br />
| || 10.50.252.44 fff-roffl || 10.50.252.45 fff-has2 ||<br />
|-<br />
| || 10.50.252.46 fff-fra1 || 10.50.252.47 fff-bbg ||<br />
|-<br />
| || <font color="grey"> 10.50.252.48 (free) </font>|| <font color="grey"> 10.50.252.49 (free) </font> ||<br />
|-<br />
| || 10.50.252.50 fff-roffl || 10.50.252.51 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.52 fff-has2 || 10.50.252.53 <font color="grey"> (free) </font> ||<br />
|-<br />
| || 10.50.252.54 fff-has2 || 10.50.252.55 fff-fra1 ||<br />
|-<br />
| || 10.50.252.56 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.57 kwadronaut ||<br />
|-<br />
| || 10.50.252.58 fff-gw-m1 || 10.50.252.59 kwadronaut ||<br />
|-<br />
| || 10.50.252.60 fff-nue1 || 10.50.252.61 kwadronaut ||<br />
|-<br />
| || 10.50.252.62 ro1 || 10.50.252.63 kwadronaut ||<br />
|-<br />
| || 10.50.252.64 staufen || 10.50.252.65 kwadronaut ||<br />
|-<br />
| || 10.50.252.66 watzmann || 10.50.252.67 kwadronaut ||<br />
|-<br />
| || 10.50.252.68 kwadronaut || 10.50.252.69 yaga ||<br />
|-<br />
| || 10.50.252.70 fff-has || 10.50.252.71 nue1 ||<br />
|-<br />
| || 10.50.252.72 fff-has || 10.50.252.73 fff-wue1 ||<br />
|-<br />
| || 10.50.252.74 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.75 fff-dns-cd1 ||<br />
|-<br />
| || 10.50.252.76 fff-has || 10.50.252.77 fff-has1 ||<br />
|-<br />
| || 10.50.252.78 fff-roffl || 10.50.252.79 fff-has1 ||<br />
|-<br />
| || 10.50.252.80 fff-has2 || 10.50.252.81 fff-has1 ||<br />
|-<br />
| || 10.50.252.82 fff-has || 10.50.252.83 fff-has3 ||<br />
|-<br />
| || 10.50.252.84 fff-has2 || 10.50.252.85 fff-has3 ||<br />
|-<br />
| || 10.50.252.86 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.87 fff-dns-cd2 ||<br />
|-<br />
| || 10.50.252.88 ro1 || 10.50.252.89 fablabnbggw ||<br />
|-<br />
| || 10.50.252.90 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.91 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.92 fff-has || 10.50.252.93 fff-has2 ||<br />
|-<br />
| || 10.50.252.94 ro1 || 10.50.252.95 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.96 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.97 fff-gw-cd2 ||<br />
|-<br />
| || 10.50.252.98 fff-gw-cd2 || 10.50.252.99 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.100 fff-gw-cd2 || 10.50.252.101 has2 ||<br />
|-<br />
| || 10.50.252.102 fff-gw-cd2 || 10.50.252.103 fff-gw-m1 ||<br />
|-<br />
| || 10.50.252.104 fff-gw-cd2 || 10.50.252.105 fff-dns-cd1 ||<br />
|-<br />
| || 10.50.252.106 fff-fr1-arm || 10.50.252.107 ro1 ||<br />
|-<br />
| || 10.50.252.250 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.251 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.252 Testsystem von [[Benutzer:ChristianD]] || 10.50.252.253 Testsystem2 von [[Benutzer:ChristianD]] ||<br />
|-<br />
! 10.83.0.0/16 || free for tests ||<br />
|-<br />
| || <font color="grey">10.83.0.1 - 10.83.255.254</font> || <br />
|-<br />
|}<br />
<br />
== Statische IP-Adressen ==<br />
Dienste müssen Ihre IP-Adressen natürlich aus dem Subnetz beziehen, in welchem sie angeschlossen sind. Damit es keine Konflikte gibt, muss die IP-Adresse hier registriert werden.<br />
<br />
=== Default Hood ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.16.0 – 10.50.17.255 || || IP-Bereich Default Hood || <br />
|-<br />
| 10.50.16.2 || fff-nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.16.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.16.11 || c.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.21 || rns3.franken.ff || DNS PoC - Recursor #3 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.16.100 || netmon.freifunk-franken.de || || [[Server#si1|Details]]<br />
|-<br />
| 10.50.16.112 ||???.franken.ff || Raspberry Pi, Test owncloud, FTP || MartinS<br />
|-<br />
| 10.50.16.128 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.150 ||Diagnose ChristianD || Diagnose ChristianD || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.16.200 ||???.franken.ff || Fileserver || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.16.212 ||???.franken.ff || NAS, verschiedene Services || JomJom<br />
|-<br />
| 10.50.16.222 ||???.franken.ff || VM, mom. nur Test || pixelchrome<br />
|-<br />
| 10.50.17.112 ||???.franken.ff || Webserver, Tests || wolli112<br />
|}<br />
<br />
=== Hood Fürth ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.32.0 – 10.50.32.255 || || IP-Bereich Fürth Hood || <br />
|-<br />
| 10.50.32.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.32.3 || fff-uk1.freifunk-franken.de || || [[Server#fff-uk1|Details]]<br />
|-<br />
| 10.50.32.4 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|- <br />
| 10.50.32.5 || [[fff-nue2|fff-nue2-gw1]] || Gateway || [[Benutzer:RedDog|RedDog]] [[Benutzer:Mayosemmel|Mayosemmel]] [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.6 || frei || ||<br />
|- <br />
| <font color="grey"> 10.50.32.7 </font>||<font color="grey"> (frei) </font> || ||<br />
|-<br />
| 10.50.32.26 || Test-PI || Statische IP des RasPI für Testzwecke || [[Benutzer:Hobo|Hobo]] <br />
|-<br />
| 10.50.32.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.32.70 || NAT für priv. Netz || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.71 || testbridgeclient.bridge.fff.community || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.100 || MicroNAS || anonymous FTP (10GB) || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.101 || Wetterstation || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Daten bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.102 || Wetterkamera || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Bilder bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.108 || williams || privater PC || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.109 || Raspi || Raspi Server im Höffner || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.110 || - || - || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.111 || stmichael.bridge.ws13.fff.community || Nanobeam M5 Bridge als AP auf St. Michael Richtung DelphiN || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.112 || ws13.bridge.stmichael.fff.community || Nanobeam M5 Bridge als Client bei DelphiN. Richtung St. Michael || [[Benutzer:delphiN|delphiN]], [[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.113 || stmichael.bridge.hoeffner.fff.community || Bridge als AP auf St. Michael. Richtung Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.114 || hoeffner.bridge.stmichael.fff.community || Bridge als Client bei Hoeffner. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.115 || clockwork.bridge.stmichael.fff.community || Bridge als Client bei Clockwork. Richtung St. Michael || [[Benutzer:clockwork|clockwork]],[[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]], <br />
|-<br />
| 10.50.32.117 || || ToughSwitch Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.118 || || ToughSwitch auf WS13 || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.119 || || ToughSwitch auf StMichael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.120 || || ToughSwitch im Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.121 || || Bridge als AP auf St. Michael. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.122 || || Bridge als Client in Europaallee. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.123 || || Reserviert: Bridge als AP auf Hardhöhe. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.124 || || Bridge als Client in Europaallee. Richtung Hardhöhe || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.150 || ChristianD's PC || FFF-Netz ohne Internet || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.151 || feste Laptop IP || Für Speedtests mit manuellen Gateway || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.152 || RasPi || Testsystem || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.170 || HoeffnerPrinter || Drucker Computerraum Höffner || [[Benutzer:delphiN|delphiN]] <br />
|-<br />
| 10.50.32.199 || || Ralphs home-server ftp/http || [[Benutzer:dk5ras|dk5ras]] <br />
|}<br />
<br />
=== Hood Nürnberg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.40.0 – 10.50.40.255 || || IP-Bereich Nürnberg Hood || <br />
|-<br />
|<strike>10.50.40.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.40.6 || fff-bbg-tmp|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.7 || fff-gw-yaga|| || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.40.8 || fff-bbg|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.10 || FFF-GW-M1 || || [[Server#FFF-GW-M1|Details]]<br />
|-<br />
| 10.50.40.11 || a.ns.franken.ff || DNS PoC - Master || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.12 || b.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.20 || - – - || Direct Connect HUB || [[Benutzer:TheFroggy|TheFroggy]]<br />
|-<br />
| 10.50.40.21 || rns1.franken.ff || DNS PoC - Recursor #1 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.22 || rns2.franken.ff || DNS PoC - Recursor #2 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| <strike>10.50.40.40</strike> || <strike>fff-synology.freifunk-franken.de</strike> || Umgezogen nach NBGLand || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.40.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.40.51 || mayo-test.fff.community || || [[Benutzer:mayosemmel|mayosemmel]]<br />
|-<br />
| 10.50.40.52 || VPN ins FF || || [[Benutzer:mayosemmel|mayosemmel]]<br />
|-<br />
| 10.50.40.66 || flightradar.freifunk-franken.de || Dump1090 || [[Benutzer:Sixkiller6kl|sixkiller6kl]]<br />
|-<br />
| 10.50.40.88 || Knotenpunkt || Test-Server || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.98 || jabber.pm-ib.de || Jabber-Server || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.99 || K4CG || Dinge-Tester || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.100 || K4CG || Dinge-Tester || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.101 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.102 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.103 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.110 || ff_br_Spenglerstr || 5-GHz-Bridge Spenglerstr --> Johannis || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.111 || ff_Johannis || 5-GHz-Bridge Johannis --> Spenglerstr || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.120 || -- || 5-GHz-Access Point (Schniegling) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.121 || -- || 5-GHz-Client (Naturfreundehaus Nürnberg Mitte) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.122 || -- || 5-GHz-Client (Quelle GU) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.123 || -- || 5-GHz-AccessPoint (Quelle, Internetanbindung) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.130 || ff_nhgbr_Johnny || 5-GHz-Master (Standort Spenglerstr) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.131 || ff_nhgbr_NHG || 5-GHz-Slave (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.132 || ff_NHG_Osten || 5-GHz-Master (Standort Nachbarschaftshaus Goho, Richtung Osten) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.135 || ff_nhgswitch_NHG || POE-Switch (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.140 || ff_TS_PoE_tmp || 5-Port POE-Switch (für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.141 || ff_NS_M5_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.142 || ff_NS_M5_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.143 || ff_PB_5AC_500_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.144 || ff_PB_5AC_500_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.145 || ff_nhgbrsüd_M5loco_Master || 5-GHz-Master (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.146 || ff_Bauerngassebr_M5loco_Slave || 5-GHz-Slave (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.200 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Client, Routerfernwartung || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.206 || --- || lokale Dienste || [[Benutzer:meskal|meskal]]<br />
|-<br />
| 10.50.40.201 – 10.50.40.205|| Test || bitte vorläufig freihalten, danke || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.230 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.231 ||???.franken.ff || Juniper SRX (VRF) || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.232 ||???.franken.ff || Raspberry Pi || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.233 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.234 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
| 10.50.43.165 || fffsvr01.franken.freifunk.net || SMB, FTP Server 250GB || [[Benutzer:ManuelS|ManuelS]]<br />
|}<br />
<br />
=== Hood Ansbach ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.48.0 – 10.50.48.255 || || IP-Bereich Ansbach Hood || <br />
|-<br />
| 10.50.48.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.48.3 || fff-gw-cdfue1 || || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| 10.50.48.20 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.21 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.48.230 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.231 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.232 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.233 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.234 || || mom. nur Test || JuzeCr<br />
|}<br />
<br />
=== Hood Hassberge ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.56.0 – 10.50.56.255 || || IP-Bereich Hassberge Hood || <br />
|-<br />
| 10.50.56.1 || fff-has1|| || [[Server#fff-has1|Details]] <br />
|-<br />
| 10.50.56.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]] <br />
|-<br />
| 10.50.56.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.56.7 || fff-roffl|| || [[Server#fff-roffl|Details]]<br />
|-<br />
| 10.50.56.8 || fff-has3 || || [[Server#fff-has3|Details]] <br />
|-<br />
| 10.50.56.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| Bitte den Bereich 10.50.56.120 – 10.50.56.129 für [[Benutzer:Plocker|Plocker]] frei lassen<br />
|-<br />
| 10.50.56.123 || Teeworlds-Game-Server || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.124 || OwnCloud + Wiki || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.125 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.126 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.132 ||<strike> Webserver + MUD? || || [[Benutzer:PeterPhilipp|area52]]</strike><br />
|}<br />
<br />
=== Hood Hassberge Süd ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.60.0 – 10.50.60.255 || || IP-Bereich HassbergeSued Hood ||<br />
|-<br />
|<strike> 10.50.60.1</strike> || <strike>fff-has1 </strike>|| || [[Server#fff-has1|Details]]<br />
|-<br />
| 10.50.60.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.60.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.60.7 || fff-roffl|| || [[Server#fff-roffl|Details]] <br />
|-<br />
| 10.50.60.10 || Webcam Meehäusle Parkplatz|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.11 || Webcam Meehäusle Biergarten|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.100 /mediawiki || Webserver Mediawiki (in progress: Wikipedia(de)offline mirror)|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.101 /wiki || Raspi Webserver mit MediaWiki (Haßberge Wiki)|| || [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Erlangen ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.64.0 – 10.50.64.255 || || IP-Bereich Erlangen Hood || <br />
|-<br />
| 10.50.64.3 || fff-gw-yaga || || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.64.4 || fff-gw-kwadro || || [[Server#fff-gw-kwadro|Details]]<br />
|-<br />
| 10.50.64.10 || radiator.franken.ff || || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.11 || voip-1.radiator.franken.ff || Outernet, VoIP mittels SIP || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.12 || cam-1.radiator.franken.ff || IP-Cam || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.20 || radiatrix.franken.ff || geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.21 || cam-1.radiatrix.franken.ff || IP-Cam, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.22 || voip-1.radiatrix.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.30 || long.franken.ff || geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.31 || cam-1.long.franken.ff || IP-Cam || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.33 || voip-1.long.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.40 |||| Streaming Erlangen (im Aufbau) || [[Benutzer:R.funkt|R.funkt]]<br />
|-<br />
| 10.50.64.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.64.60 || gate3 || Dev || [[Benutzer:Jonas-bebe|Jonas-bebe]]<br />
|-<br />
| 10.50.64.70 |||| Raspi-Test || [[Benutzer:Dieter123|Dieter123]]<br />
|-<br />
| 10.50.64.78 |||| IP-CAM || [[Benutzer:moonrat|moonrat]]<br />
|-<br />
| 10.50.64.79 |||| IP-CAM || [[Benutzer:moonrat|moonrat]]<br />
|}<br />
<br />
=== Hood Würzburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.72.0 – 10.50.79.255 || || IP-Bereich Würzburg Hood || <br />
|-<br />
| 10.50.72.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.72.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.72.6 || fff-wue1|| || [[Server#fff-wue1|Details]] <br />
|-<br />
| 10.50.72.7 || kleeV2|| || [[Server#kleeV2|Details]] <br />
|-<br />
| 10.50.72.9 || Raspi-test|| || [[MisterCrumble|MisterCrumble]]<br />
|-<br />
| 10.50.72.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.72.72 || WikipediaClon || Soll ein Clon der Wikipedia werden. || [[Benutzer:Luensche|Luensche]]<br />
|-<br />
| 10.50.72.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood BGL ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.80.0 – 10.50.87.255 || || IP-Bereich BGL Hood || <br />
|-<br />
| 10.50.80.1 || watzmann || ||<br />
|-<br />
| 10.50.80.2 || staufen || ||<br />
|}<br />
<br />
=== Hood Nürnberger-Land ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.88.0 – 10.50.95.255 || || IP-Bereich NbgLand Hood || <br />
|-<br />
| 10.50.88.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.88.10 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.11 || fff-gw-cdnbgland2 || Gateway (Testbetrieb) || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.40 || fff-synology.freifunk-franken.de || Umzug nach Hood-Teilung || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.88.170 ||???.franken.ff || 5-GHz Richtfunk AP || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.171 ||???.franken.ff || 5-GHz Richtfunk Client || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.172 ||???.franken.ff || VM zum Testen || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood Aschaffenburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.96.0 – 10.50.103.255 || || IP-Bereich Aschaffenburg || <br />
|-<br />
| 10.50.96.x || fff-res|| || <br />
|-<br />
| 10.50.96.3 || fff-has || Gateway [[Server#fff-has|Details]]<br />
|| [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Hof ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.104.0 – 10.50.111.255 || || IP-Bereich Hof || <br />
|-<br />
| 10.50.104.1 || fff-has1 || Gateway [[Server#fff-has1|Details]]<br />
|| [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.104.2 || fff-fr1-arm || Gateway || [[User:RedDog]]<br />
|-<br />
| 10.50.104.10 || fff-gw-cdhof1 || Gateway || ChristianD<br />
|}<br />
<br />
=== Hood FabLabnbg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.132.0 – 10.50.134.255 || || IP-Bereich FabLabnbg || <br />
|-<br />
| 10.50.132.1 || fablab || Gateway FabLabnbg || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|-<br />
| 10.50.132.2 || Switch || Switch || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|-<br />
| 10.50.132.9 || Raspberry Pi || Für Alfredmaster || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.132.10 || 5GHz Test || 5GHz Test || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|}<br />
<br />
=== Hood Hardhöhe ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.130.0 – 10.50.131.255 || || IP-Bereich Hardhöhe || <br />
|-<br />
| 10.50.130.1 || fff-gw-db0fue1 || Gateway Hardhöhedach || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.11 || fff-5gs1-hhd || erste LBE-5AC-16-120 || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.12 || fff-5gs2-hhd || zweite LBE-5AC-16-120 || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|}<br />
<br />
=== Hood Aux ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
!10.50.240.1 – 10.50.247.254 || || IP-Bereich aux Hood || <br />
|-<br />
| 10.50.240.1 || fff-bbg || ||<br />
|-<br />
| 10.50.240.2 || fff-fra1 || ||<br />
|-<br />
| 10.50.240.3 || fff-gw-cdaux2 || ||<br />
|-<br />
| 10.50.240.20 || || Testgateway Flo für Hotel Busch |||<br />
|-<br />
| 10.50.240.11 || AP.bridge1.hoeffner.fff.community || Bridge AP Höffner || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.12 || S01.bridge1.hoeffner.fff.community || Bridge Station Hardhöhe || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.100 || fff-client-auxcd1 || Client zur Fernwartung aux || [[Benutzer:ChristianD|ChristianD]] ||<br />
|}<br />
<br />
= BSSID =<br />
<br />
{|<br />
! BSSID !! Hood !!<br />
|-<br />
| 00:ca:ff:ee:ba:be || legacy ||<br />
|-<br />
| ca:ff:ee:ba:be:00 || Trainstation ||<br />
|-<br />
| ca:ff:ee:ba:be:02 || Fürth || <br />
|-<br />
| ca:ff:ee:ba:be:03 || Nürnberg ||<br />
|-<br />
| ca:ff:ee:ba:be:04 || FabLabNbg ||<br />
|-<br />
| ca:ff:ee:ba:be:05 || Hardhöhe ||<br />
|}</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Server&diff=6580
Server
2016-05-15T07:13:12Z
<p>Green: /* Gateway Server */</p>
<hr />
<div>{{Entwurf}}<br />
<br />
__TOC__<br />
<br />
= Gateway Server = <br />
<br />
== Gateway Server fff-fra1 ==<br />
<br />
[[Server/fff-fra1|Details gibts hier...]]<br />
<br />
== Gateway Server "ro1" ==<br />
'''IP/Domain:''' ???<br />
<br />
'''Standort:''' Rumänien<br />
<br />
'''Owner:''' [[Benutzer:TheFroggy]]<br />
<br />
'''OLSR-Infos:''' [http://10.50.32.1:8080/all http://10.50.32.1:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''Admins:'''<br />
* [[Benutzer:RedDog]] <br />
* [[Benutzer:Casandro]]<br />
* [[Benutzer:Magenbrot]]<br />
<br />
'''Funktion:'''<br />
* Internet Uplink (direkt)<br />
* DNS<br />
* ICVPN Knoten<br />
* Jabber<br />
* IPIP Tunnel zu anderen GWs<br />
* IPv4 Gateway (dhcp) für<br />
** Default-Hood<br />
** Fürth<br />
** Nürnberg<br />
** Ansbach<br />
** Erlangen<br />
<br />
'''Monitoring'''<br />
* URL: https://monitor.ovtec.de/icinga/<br />
* User: freifunk_ro<br />
* Pass: TeUa-w8q_o6wUh4ZuW<br />
<br />
== Gateway Server "fff-nue1" ==<br />
'''IP/Domain:''' fff-nue1.wavecloud.de<br />
<br />
'''Standort:''' Noris Networks, Nürnberg<br />
<br />
'''Owner:''' [https://www.wavecon.de Wavecon GmbH]<br />
<br />
'''OLSR-Infos:''' [http://10.50.32.2:8080/all http://10.50.32.2:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''Admins'''<br />
* [[Benutzer:Magenbrot]]<br />
* [[Benutzer:DelphiN]]<br />
* [[Benutzer:Corny]]<br />
* [[Benutzer:RedDog]]<br />
<br />
'''Funktion:'''<br />
* Key-Exchange-Server: [http://keyserver.freifunk-franken.de/fff/ keyserver.freifunk-franken.de]<br />
* Internet Uplink (vpn03 [Freie Netze eV])<br />
* DNS<br />
* IPIP Tunnel zu ro1<br />
* IPIP Tunnel zu fff-has<br />
* IPv4 Gateway (dhcp) für<br />
** Default-Hood<br />
** Fürth<br />
** Ansbach<br />
** Erlangen<br />
** Würzburg<br />
<br />
== Gateway Server "fff-uk1" ==<br />
'''IP/Domain:''' ???<br />
<br />
'''Standort:''' UK<br />
<br />
'''Owner:''' [[Benutzer:RedDog]]<br />
<br />
'''OLSR-Infos:''' <strike>[http://10.50.32.3:8080/all http://10.50.32.3:8080/all] (Nur Freifunk-Intern)</strike><br />
<br />
'''Admins'''<br />
* [[Benutzer:RedDog]]<br />
* Meskal<br />
<br />
'''Funktion:'''<br />
* Internet Uplink (direkt)<br />
* DNS<br />
* IPv6 Gateway für<br />
** Fürth<br />
<br />
== Gateway Server "fff-has" ==<br />
'''IP/Domain:''' 78.47.36.148<br />
<br />
'''Standort:''' Falkenstein<br />
<br />
'''Owner:''' [[Benutzer:Moexe]]<br />
<br />
'''OLSR-Infos:''' [http://10.50.60.3:8080 OLSR-http-info] (nur Freifunk intern!)<br />
<br />
'''Traffic-Statistic''' [http://fff-has.freifunk-hassberge.de MRTG] <br />
<br />
'''Admins'''<br />
* [[Benutzer:Moexe]]<br />
'''Funktion:'''<br />
* VPN über Perfect Privacy nach Holland<br />
* IPIP Tunnel zu ro1<br />
* IPIP Tunnel zu fff-nue1<br />
* IPIP Tunnel zu fff-has1<br />
* IPIP Tunnel zu fff-has2<br />
* IPIP Tunnel zu fff-wue1<br />
* IPIP Tunnel zu roffl<br />
<br />
* IPv4 Gateway (dhcp) für<br />
** Haßberge Süd<br />
<br />
== Gateway Server "fff-has1" ==<br />
'''IP/Domain:''' 78.47.161.124<br />
<br />
'''Standort:''' Falkenstein<br />
<br />
'''Owner:''' [[Benutzer:Moexe]]<br />
<br />
'''OLSR-Infos:''' [http://10.50.60.1:8080/all http://10.50.60.3:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''Traffic-Statistic [http://fff-has1.freifunk-hassberge.de MRTG] ''' <br />
<br />
'''Admins'''<br />
* [[Benutzer:Moexe]]<br />
'''Funktion:'''<br />
* VPN über Perfect Privacy nach Holland<br />
* IPIP Tunnel zu fff-has<br />
* IPIP Tunnel zu fff-roffl<br />
* IPIP Tunnel zu fff-has2<br />
* IPv4 Gateway (dhcp) für<br />
** Haßberge<br />
<br />
== Gateway Server "fff-has2" ==<br />
'''IP/Domain:''' 5.196.164.9<br />
<br />
'''Standort:''' Frankfurt<br />
<br />
'''Owner:''' [[Benutzer:Plocker]]<br />
<br />
'''OLSR-Infos:''' [http://5.196.164.9:8080/all http://5.196.164.9:8080/all]<br />
<br />
'''mrtg-Infos:''' [http://5.196.164.9/ http://5.196.164.9/]<br />
<br />
'''Admins'''<br />
*[[Benutzer:Plocker]] <br />
*[[Benutzer:Moexe]]<br />
<br />
'''Funktion:'''<br />
* VPN über Mullvad nach Holland<br />
* IPIP Tunnel zu ro1<br />
* IPIP Tunnel zu bbg<br />
* IPIP Tunnel zu fra1<br />
* IPIP Tunnel zu fff-nue1<br />
* IPIP Tunnel zu fff-has<br />
* IPIP Tunnel zu fff-has1<br />
* IPIP Tunnel zu fff-has3<br />
* IPIP Tunnel zu fff-wue1<br />
* IPIP Tunnel zu fff-gw-cdfue1<br />
* IPIP Tunnel zu fff-mayo<br />
* IPIP Tunnel zu fff-roffl<br />
* IPIP Tunnel zu kleeV2<br />
* IPv4 Gateway (dhcp) für<br />
** Haßberge<br />
** Haßberge Süd<br />
<br />
== Gateway Server "fff-roffl" ==<br />
'''IP/Domain:''' 176.123.28.108<br />
<br />
'''Standort:''' Frankfurt<br />
<br />
'''Owner:''' [[Benutzer:roffl1990]]<br />
<br />
'''OLSR-Infos:''' [http://10.50.60.7:8080/all http://10.50.60.7:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''Admins'''<br />
*[[Benutzer:roffl1990]] <br />
*[[Benutzer:Plocker]] <br />
*[[Benutzer:Moexe]]<br />
<br />
'''Funktion:'''<br />
* IPIP Tunnel zu fff-has<br />
* IPIP Tunnel zu fff-has2<br />
* IPv4 Gateway (dhcp) für<br />
** Haßberge<br />
** Haßberge Süd<br />
<br />
== Gateway Server "fff-has3" ==<br />
'''IP/Domain:''' ???<br />
<br />
'''Standort:''' München<br />
<br />
'''Owner:''' [[Benutzer:wrhofheim]]<br />
<br />
'''OLSR-Infos:''' [http://10.50.60.8:8080/all http://10.50.60.8:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''Admins'''<br />
*[[Benutzer:wrhofheim]] <br />
*[[Benutzer:Moexe]] <br />
*[[Benutzer:Plocker]]<br />
<br />
'''Funktion:'''<br />
* VPN über Mullvad nach Holland<br />
* IPIP Tunnel zu fff-has1<br />
* IPIP Tunnel zu fff-has2<br />
* IPv4 Gateway (dhcp) für<br />
** Haßberge<br />
<br />
== Gateway Server "watzmann" ==<br />
'''IP/Domain:''' 10.50.80.1<br />
<br />
'''Standort:''' Webhod Networks GbR, Frankfurt<br />
<br />
'''Owner:''' [[Benutzer:mrtnschn]]<br />
<br />
<br />
'''OLSR-Infos:''' [http://10.50.60.1:8080/all http://10.50.60.1:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''Admins'''<br />
*[[Benutzer:Fffbamberg]] <br />
<br />
<br />
'''Funktion:'''<br />
* VPN über Cyberghost nach Holland<br />
* IPv4 Gateway (dhcp) für<br />
** Bamberg<br />
<br />
== Gateway Server "fff-gw-cd1" ==<br />
'''IP/Domain:''' fff-gw-cd1.fff.community<br />
<br />
'''Standort:''' Falkenstein - Hetzner<br />
<br />
'''Owner:''' [[Benutzer:ChristianD]]<br />
<br />
<br />
'''Admins:'''<br />
* [[Benutzer:ChristianD]]<br />
<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via OpenVPN (Mullvad)<br />
* GRE-Tunnel für OSLR zu anderen Gateways (kleeV2, fff-gw-m1, has2, ro1, fff-pi-cd1, fff-dns-cd1. fff-dns-cd2, kwadronaut, fff-gw-cd2)<br />
* IPv4 Internetgateway (dhcp) für<br />
** Fürth 'fff-gw-cdfue1'<br />
** Ansbach 'fff-gw-cdan1'<br />
** Hof 'fff-gw-cdhof1'<br />
* Client in Nürnberg & aux & default zur Routerfernwartung und Hooddiagnose außerhalb der eigenen Hood<br />
* nbgland Backup (noch Gatewaybit wird entfernt wenn alles stabil läuft)<br />
* Owncloud Server (Testbetrieb URL folgt...)<br />
<br />
<br />
'''Statistiken:'''<br />
* Statistiken: [http://fff-gw-cd1.fff.community/index.php http://fff-gw-cd1.fff.community/index.php]<br />
<br />
== Gateway Server "fff-gw-cd2" ==<br />
'''IP/Domain:''' folgt...<br />
<br />
'''Standort:''' Scaleway Frankreich<br />
<br />
'''Owner:''' [[Benutzer:ChristianD]]<br />
<br />
<br />
'''Admins:'''<br />
* [[Benutzer:ChristianD]]<br />
<br />
'''Besonderheit:'''<br />
* 4 Kern dedizierte ARM Prozessoren mit jeweils 1333MHZ pro CPU<br />
* Kein eigener DNS Server, es werden die Peeringips von fff-gw-cd1 und fff-gw-m1 als DNS Server ausgeliefert<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via OpenVPN (Mullvad)<br />
* GRE-Tunnel für OSLR zu anderen Gateways (fff-gw-cd1, fff-gw-m1, has2, )<br />
* IPv4 Internetgateway (dhcp) für<br />
** nbgland 'fff-gw-cdnbgland2'<br />
<br />
<br />
<br />
'''Statistiken:'''<br />
* Statistiken: folgt...<br />
<br />
== Internet Exit Server "fff-pi-cd1" ==<br />
'''IP/Domain:''' folgt<br />
<br />
'''Standort:''' [http://raspberry-host.de/ Raspberry Host]<br />
<br />
'''Owner:''' [[Benutzer:ChristianD]]<br />
<br />
<br />
'''Admins:'''<br />
* [[Benutzer:ChristianD]]<br />
<br />
'''Funktion:'''<br />
* Internetexit über Mullvad<br />
<br />
'''Statistiken:'''<br />
* [http://37.228.135.203/vnstat/ vnstat]<br />
<br />
== Gateway Server "fff-wue1" ==<br />
''' IP/Domain:''' 10.50.72.6<br />
<br />
''' Standort:''' Falkenstein (Hetzner)<br />
<br />
'''Owner:''' [[Benutzer:mifritscher]]<br />
<br />
<br />
'''Admins:'''<br />
* [[Benutzer:mifritscher]]<br />
<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via OpenVPN (Mullvad, Niederlande)<br />
* GRE-Tunnel für OSLR zu anderen Gateways <br />
** fff-has (10.50.72.3)<br />
** fff-has2 (10.50.56.3)<br />
** fff-has3 (10.50.56.6; per IPv6) - derzeit deaktiviert<br />
* IPv4 Internetgateway (dhcp) für<br />
** Würzburg<br />
** Nürnberg - derzeit deaktiviert<br />
** Nbg-Land<br />
<br />
'''Statistiken:'''<br />
* Allgemeine Statistik zum Server: [http://188.40.170.116/monitoring/i.html]<br />
* Auslastung und Traffic Statistik: [http://10.50.72.6/mrtg http://10.50.72.6/mrtg] (nur Freifunk intern) oder [http://188.40.170.116/mrtg http://188.40.170.116/mrtg]<br />
* OLSR-Infos: [http://10.50.72.6:8080/all http://10.50.72.6:8080/all] (nur Freifunk intern) oder [http://188.40.170.116:8080/all http://188.40.170.116:8080/all]<br />
<br />
''' Hinweise '''<br />
Der Server wurde nach [[Freifunk-Gateway_aufsetzen]] aufgesetzt, die Statistik-Seite nach [[Portal:Netz/Statistiken]] erstellt. Außerdem wurde die DNS-Konfig nach https://wiki.freifunk-franken.de/w/DNS#Static-Stub_Konfiguration durchgeführt.<br />
<br />
== Gateway Server "FFF-GW-M1" ==<br />
<br />
''' IP/Domain:''' 10.50.40.10<br />
<br />
''' Standort:''' Deutschland (netcup)<br />
<br />
'''Owner:''' [[Benutzer:mayosemmel]]<br />
<br />
<br />
'''Admins:'''<br />
* [[Benutzer:mayosemmel]]<br />
<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via OpenVPN (Mullvad, Land wechselnd je nach Performance)<br />
* Gateway zum IC-VPN [https://wiki.freifunk.net/IC-VPN]<br />
* GRE-Tunnel für OSLR zu anderen Gateways <br />
* IPv4 Internetgateway (dhcp) für<br />
** Nürnberg<br />
<br />
'''Statistiken:'''<br />
* OLSR-Infos: [http://10.50.40.10:8080/all http://10.50.40.10:8080/all] (nur Freifunk intern)<br />
* Weitere Statistiken: [http://10.50.40.10 http://10.50.40.10] (nur Freifunk intern)<br />
<br />
== Gateway Server "fff-gw-yaga" ==<br />
''' IP/Domain:''' 10.50.40.7<br />
<br />
''' Standort:''' Düsseldorf<br />
<br />
'''Owner:''' [[Benutzer:yaga]]<br />
<br />
'''OLSR-Infos:''' [http://10.50.40.7:8080/all http://10.50.40.7:8080/all] (nur Freifunk intern)<br />
<br />
'''Admins:'''<br />
* [[Benutzer:yaga]]<br />
<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via OpenVPN (privateinternetaccess, Holland)<br />
* GRE-Tunnel für OLSR zu anderen Gateways <br />
** fff-wue1 (10.50.252.22 <-> 10.50.252.23)<br />
** ro1 (10.50.252.40 <-> 10.50.252.41)<br />
** nue1 (10.50.252.42 <-> 10.50.252.43)<br />
* IPv4 Internetgateway (dhcp) für<br />
** Nürnberg<br />
** Erlangen<br />
<br />
== Gateway Server "fff-bbg" ==<br />
'''IP/Domain:''' 78.46.181.112/bbg.meskalero.de<br />
<br />
'''Standort:''' Falkenstein - Hetzner<br />
<br />
'''Owner:''' [[Benutzer:meskal]]<br />
<br />
'''Admins:'''<br />
* [[Benutzer:meskal]]<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via olsr-Layer3 meshing<br />
* GRE-Tunnel für OLSR zu anderen Gateways <br />
** fff-fra1<br />
** fff-ro1<br />
** fff-nue1<br />
** fff-wue1<br />
** fff-has2<br />
** fff-klee<br />
* IPv4 Internetgateway (dhcp) für<br />
** Nürnberg<br />
** aux<br />
'''Statistik'''<br />
** http://bbg.meskalero.de/CGP/host.php?h=bbg.meskalero.de<br />
<br />
== Gateway Server "fff-kwadro" ==<br />
'''IP/Domain:''' 78.46.210.151<br />
<br />
'''Standort:''' Hetzner<br />
<br />
'''Owner:''' [[Benutzer:Kwadronaut]]<br />
<br />
'''Admins:'''<br />
* [[Benutzer:Kwadronaut]]<br />
<br />
'''Funktion:'''<br />
* GRE-Tunnel für OLSR zu anderen Gateways <br />
** fff-staufen<br />
** fff-ro1<br />
** fff-nue1<br />
** fff-watzmann<br />
** fff-cd1<br />
** fff-m1<br />
* IPv4 Internetgateway (dhcp) für<br />
** Erlangen (geplant)<br />
'''Statistik'''<br />
** sollte ich mal bauen<br />
<br />
= Sonstige Server =<br />
<br />
== Netmon Server "fff-netmon1" ==<br />
'''IP/Domain:''' fff-netmon1.wavecloud.de<br />
<br />
'''Standort:''' Nürnberg<br />
<br />
'''Owner:''' wavecloud.de<br />
<br />
'''Admins'''<br />
* [[Benutzer:Magenbrot]]<br />
* [[Benutzer:RedDog]]<br />
* Meskal<br />
* mrtnmb<br />
<br />
'''Funktion:'''<br />
* Netmon<br />
* ntdp<br />
* Keyxchange (/var/www/keyserver/fff/)<br />
<br />
== Webserver "fff_wiki1" ==<br />
'''IP/Domain:''' odin.ovtec.it<br />
<br />
'''Standort:''' Nürnberg<br />
<br />
'''Owner:''' [[Benutzer:magenbrot]]<br />
<br />
'''Admins'''<br />
* [[Benutzer:magenbrot]]<br />
<br />
'''Funktion:'''<br />
* [https://wiki.freifunk-franken.de wiki.freifunk.franken.de]<br />
* [http://ftp.freifunk-franken.de ftp.freifunk-franken.de]<br />
<br />
== fff-nue2.fff.community ==<br />
* Host-System für versch. VMs:<br />
** todo ..<br />
<br />
Siehe auch [[Server/fff-nue2]]<br />
<br />
[[Kategorie:Technik]]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Portal:Netz&diff=6579
Portal:Netz
2016-05-15T07:11:47Z
<p>Green: /* Hood Aux */</p>
<hr />
<div>== Das Netz ==<br />
Eine Karte der aktiven Router gibt es [https://monitoring.freifunk-franken.de/map].<br />
<br />
Eine Karte der Hoods ist [http://keyserver.freifunk-franken.de/fff/voronoimap.php hier] zu finden.<br />
<br />
Die [https://monitoring.freifunk-franken.de/routers Liste der Router] kann dank Monitoring immer live verfolgt werden. Infos über die Schreibweise (z.B. "/20") gibt es in der [http://de.wikipedia.org/wiki/CIDR Wikipedia].<br />
<br />
=== Gateway ===<br />
Erste Versuche einer sinnvollen Aufteilung von Gateways. Erweiterungen und Verbesserungen sind jederzeit erwünscht. [https://pad.freifunk.net/p/Gatewayaufteilung-Franken Zum Pad]<br />
<br />
== IP-Netz ==<br />
Mit der Netz-Umstellung vom 22.03.2014 haben wir nicht mehr länger ein großes [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_2_.E2.80.93_Sicherungsschicht_.28Data_Link_Layer.29 Layer-II-Netz], welches durch das [https://de.wikipedia.org/wiki/B.A.T.M.A.N. B.A.T.M.A.N. advanced]-Protokoll geroutet wird. Seitdem gibt es mehrere [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_3_.E2.80.93_Vermittlungsschicht_.28Network_Layer.29 Layer-III-Netze] (Hoods). Ein Layer-III-Netz entsteht grundsätzlich, indem hier ein Subnetz eingetragen wird. Wie dabei genau vorgegangen wird, steht in [[HoodVerwaltung]].<br />
Für jedes Subnetz muss separat abgewogen werden, wie groß es werden wird und wo es dann in die bestehenden Subnetze am besten eingegliedert werden kann.<br />
<br />
==== DHCP ====<br />
[[Datei:Hoods.png|200px|thumb|right|Vorschlag für die Hood-Organisation]]<br />
Damit simple Clients das neue Subnetz nutzen können, muss ein eigener DHCP-Server pro Subnetz bereit gestellt werden. Es macht dabei häufig Sinn, das Subnetz in IP-Bereiche aufzuteilen, die von mehreren DHCP-Servern verteilt werden. Ein zweiter DHCP-Server ermöglicht zum einen eine Lastverteilung, zum anderen erhöht sich die Ausfallsicherheit. Der DHCP-Server muss den Clients ein Default-Gateway und mindestens einen DNS-Server zuweisen. Da das Default-Gateway ebenfalls innerhalb des Subnetzes liegen muss, bietet es sich an, den selben Server, auf dem das DHCP läuft, zu nutzen.<br />
<br />
==== OLSR-Router ====<br />
Das Subnetz muss anschließend an das vorhandene Freifunknetz angeschlossen werden. Dazu muss eine Verbindung zu einem bestehenden OLSR-Router aufgebaut werden. Dies kann eine VPN-Verbindung, aber auch eine Wifi-Verbindung sein und muss individuell zwischen den zwei Parteien ausgehandelt werden. Es kann sinnvoll sein, Verbindungen zu mehr als einem OLSR-Router zu haben. Sobald der eigene Router an das OLSR-Netz angebunden ist, ist er selbst ein OLSR-Router.<br />
<br />
An den eigenen OLSR-Router können nun Accesspoints angeschlossen werden. Dies kann per VPN, WLAN, Kabel oder anderweitig geschehen. Es ist auch möglich, den Accesspoint selbst als OLSR-Router anzubinden. Auch diese Konfiguration ist individuell zu klären. Ein Accesspoint kann ein (oder mehrere) einfacher Wifi-AP oder auch ein Array von mehreren B.A.T.M.A.N.-Knoten sein. Es sollte vermieden werden, dass sich Subnetze vermischen. Dies würde immer dann passieren, wenn zwei Layer-II-Netze, die eigentlich unterschiedliche Subnetze verteilen, verbunden werden. Besonders beim B.A.T.M.A.N.-Protokoll besteht hier leicht diese Gefahr; daher sollte für jedes Subnetz eine eigene BSSID und ESSID gewählt werden.<br />
<br />
==== Aus Routersicht ====<br />
Nur Router in einer Hood können sich per B.A.T.M.A.N. advanced vermaschen, sowohl per VPN, also auch per WLAN. Daher müssen Router die räumlich nahe beieinander stehen auch in derselben Hood sein. Durch das Vermaschen des Netzes wird allerdings auch Verwaltungs-Verkehr erzeugt (Overhead). Je größer die Hood, desto größer der Overhead.<br />
<br />
Eine Verbindung zwischen Routern in unterschiedlichen Hoods ist per IP (OSI Schicht 3) möglich.<br />
<br />
Wenn im Netmon kein Standort eingegeben wurde, dann landet der Router in der Dafault-Hood.<br />
<br />
==== Monitoring (Netmon) ====<br />
Aktuell können sich Knoten nur über ein IPv6-Link-Local-Interface beim Netmon anmelden und Netmon kann die Knoten nur über eine IPv6-Link-Local-Adresse abfragen. Hier muss ein neuer Mechanismus gefunden werden, der es ermöglicht, die Knoten über Subnetze hinweg anzusprechen.<br />
<br />
Als Workaround ist es möglich, über einen Layer-II-Tunnel zum Netmon-Server das Subnetz an das Netmon anzubinden. Auf dem Netmon-Server werden alle Subnetze in einem Bridge-Interface zusammengefasst, welches keine Pakete weiterleiten kann.<br />
<br />
==== Wireless-LAN ====<br />
Wir haben uns auf folgende WLAN-Parameter verständigt:<br />
'''ESSID: franken.freifunk.net'''. Kanal 1.<br />
<br />
== Liste der Subnetze ==<br />
{|<br />
! !! Bereich !! Bereitgestellt durch<br />
|-<br />
! 10.50.0.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.0.1 – 10.50.15.254</font> || <br />
|-<br />
! 10.50.16.0/20 || Default Hood ||<br />
|-<br />
| || 10.50.16.1 – 10.50.17.255 || Statische Adressen<br />
|-<br />
| || 10.50.18.0 – 10.50.19.255 || --<br />
|-<br />
| || 10.50.20.0 – 10.50.21.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey">10.50.22.0 – 10.50.23.254 </font> || <br />
|-<br />
| || <font color="grey">10.50.24.0 – 10.50.31.254 </font> || <br />
|-<br />
! 10.50.32.0/21 || Fürth Hood ||<br />
|-<br />
| || 10.50.32.1 – 10.50.32.255 || Statische Adressen<br />
|-<br />
| || 10.50.33.0 – 10.50.34.255 || [[fff-nue2|fff-nue2-gw1]]<br />
|-<br />
| || 10.50.35.0 – 10.50.36.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey"> 10.50.37.0 – 10.50.37.255 </font> || --<br />
|-<br />
| || 10.50.38.0 – 10.50.39.254 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.40.0/21 || Nürnberg Hood ||<br />
|-<br />
| || 10.50.40.1 – 10.50.40.255 || Statische Adressen<br />
|-<br />
| || 10.50.41.0 – 10.50.42.255 || [[Server#FFF-GW-M1|FFF-GW-M1]]<br />
|-<br />
| || <font color="grey"> 10.50.43.0 - 10.50.43.255 </font> || <br />
|-<br />
| || 10.50.44.0 – 10.50.44.255 || (umgezogen) [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| ||10.50.45.0 – 10.50.46.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.47.0 – 10.50.47.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.48.0/21 || Ansbach Hood ||<br />
|-<br />
| || 10.50.48.1 – 10.50.48.255 || Statische Adressen<br />
|-<br />
| || 10.50.49.0 – 10.50.50.255 || <br />
|-<br />
| || 10.50.51.0 – 10.50.52.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.53.0 – 10.50.54.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| || <font color="grey">10.50.55.0 – 10.50.55.254</font> || <br />
|-<br />
! 10.50.56.0/22 || Hassberge Hood ||<br />
|-<br />
| || 10.50.56.1 – 10.50.56.255 || Statische Adressen<br />
|-<br />
| || 10.50.57.0 – 10.50.57.255 || [[Server#fff-has3|fff-has3]]<br />
|-<br />
| || 10.50.58.0 – 10.50.58.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.59.0 – 10.50.59.254 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
! 10.50.60.0/22 || HassbergeSued Hood ||<br />
|-<br />
| || 10.50.60.1 – 10.50.60.255 || Statische Adressen<br />
|-<br />
| || 10.50.61.0 – 10.50.61.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
| || 10.50.62.0 – 10.50.62.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.63.0 – 10.50.63.254 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
! 10.50.64.0/21 || Erlangen Hood ||<br />
|-<br />
| || 10.50.64.1 – 10.50.64.255 || Statische Adressen<br />
|-<br />
| || 10.50.65.0 – 10.50.66.255 || [[Server#fff-gw-kwadro|fff-gw-kwadro]]<br />
|-<br />
| || 10.50.67.0 – 10.50.68.255 || free<br />
|-<br />
| || 10.50.69.0 – 10.50.71.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.72.0/21 || Würzburg Hood ||<br />
|-<br />
| || 10.50.72.1 – 10.50.72.255 || Statische Adressen<br />
|-<br />
| || <font color="grey"> 10.50.73.0 – 10.50.74.255 </font>|| <br />
|-<br />
| || 10.50.75.0 – 10.50.76.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.77.0 – 10.50.78.255 || [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || 10.50.79.0 – 10.50.79.254 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
! 10.50.80.0/21 || BGL ||<br />
|-<br />
| || 10.50.80.1 – 10.50.80.255 || Statische Adressen<br />
|-<br />
| || 10.50.81.0 – 10.50.82.255 || [[Server#watzmann|watzmann]]<br />
|-<br />
| || 10.50.83.0 – 10.50.84.255 || [[Server#staufen|staufen]]<br />
|-<br />
! 10.50.88.0/21 || NbgLand Hood ||<br />
|-<br />
| || 10.50.88.1 – 10.50.88.255 || Statische Adressen<br />
|-<br />
| || 10.50.89.0 – 10.50.89.255 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| || 10.50.90.0 - 10.50.91.255 || fff-gw-cdnbgland2 (Testbetrieb)<br />
|-<br />
| || <font color="grey">10.50.92.0 - 10.50.93.255</font> || <br />
|-<br />
| || 10.50.94.0 – 10.50.95.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.96.0/21 || Aschaffenburg Hood ||<br />
|-<br />
| || 10.50.96.1 – 10.50.96.255 || Statische Adressen<br />
|-<br />
| || 10.50.97.1 – 10.50.97.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
! 10.50.104.0/21 || Hof Hood ||<br />
|-<br />
| || 10.50.104.1 – 10.50.104.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.105.0 - 10.50.106.255</font> || free<br />
|-<br />
| || 10.50.107.0 – 10.50.107.255 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
| || 10.50.108.0 - 10.50.109.255 || fff-fr1-arm<br />
|-<br />
| || 10.50.110.1 - 10.50.111.254 || fff-gw-cdhof1<br />
|-<br />
! 10.50.112.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.112.1 – 10.50.119.254</font> || <br />
|-<br />
! 10.50.120.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.120.1 – 10.50.127.254</font> || <br />
|-<br />
! 10.50.128.0/24 || Test von Casandro ||<br />
|-<br />
| || 10.50.128.20 – 10.50.128.200 || 10.50.128.1<br />
|-<br />
! 10.50.129.0/24 || free ||<br />
|-<br />
| || 10.50.129.0 || free<br />
|-<br />
! 10.50.130.0/23 || Hardhöhe ||<br />
|-<br />
| || 10.50.130.1 - 10.50.130.255 || Statische Adressen<br />
|-<br />
| || 10.50.131.0 – 10.50.131.127 || Gateway Hochhaus<br />
|-<br />
! 10.50.132.0/22 || FabLabNbg Hood ||<br />
|-<br />
| || 10.50.132.1 - 10.50.132.255 || Statische Adressen<br />
|-<br />
| || 10.50.133.0 – 10.50.133.255 || FabLabNbgGW<br />
|-<br />
| || 10.50.134.0 - 10.50.135.254 || frei<br />
|-<br />
! 10.50.136.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.136.1 – 10.50.143.254</font> || <br />
|-<br />
! 10.50.144.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.144.1 – 10.50.159.254</font> || <br />
|-<br />
! 10.50.160.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.160.1 – 10.50.191.254</font> || <br />
|-<br />
! 10.50.192.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.192.1 – 10.50.223.254</font> || <br />
|-<br />
! 10.50.224.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.224.1 – 10.50.239.254</font> || <br />
|-<br />
! 10.50.240.0/21 || fffaux ||<br />
|-<br />
| || 10.50.240.1 – 10.50.240.255 || Statische Adressen<br />
|-<br />
| || 10.50.241.0 – 10.50.241.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.242.0 – 10.50.243.255 || [[Server#fff-fra1|fff-fra1]]<br />
|-<br />
| || 10.50.244.0 – 10.50.244.127 || Testinstallation Busch (Flo)<br />
|-<br />
| || <font color="grey"> 10.50.244.128 - 10.50.245.255 </font> || | <font color="grey"> (free) </font><br />
|-<br />
| || 10.50.246.0 - 10.50.247.254 || fff-gw-cdaux2<br />
|-<br />
<br />
! 10.50.248.0/22 || free ||<br />
|-<br />
| || 10.50.248.1 – 10.50.248.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.249.0 - 10.50.251.254</font> || <br />
|-<br />
! 10.50.252.0/22 || TUNNEL ||<br />
|-<br />
| || 10.50.252.0 fff_ro1 || 10.50.252.1 nue1 || <br />
|-<br />
| || 10.50.252.2 fff_ro1 || 10.50.252.3 watzmann || <br />
|-<br />
| || 10.50.252.4 fff_ro1 || 10.50.252.5 staufen || <br />
|-<br />
| || 10.50.252.6 fff_ro1 || 10.50.252.7 has2 || <br />
|-<br />
| || 10.50.252.8 fff_ro1 || 10.50.252.9 has || <br />
|-<br />
| || 10.50.252.10 ro1 || 10.50.252.11 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.12 fff-has2 || 10.50.252.13 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.14 fff-gw-m1 || 10.50.252.15 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || <font color="grey"> 10.50.252.16 (free) </font>|| 10.50.252.17 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || <font color="grey"> 10.50.252.18 (free)</font> || 10.50.252.19 nue1 ||<br />
|-<br />
| || 10.50.252.20 <font color="grey"> (free) </font> || 10.50.252.21 ro1 ||<br />
|-<br />
| || 10.50.252.22 fff-gw-yaga || 10.50.252.23 fff-wue1 ||<br />
|-<br />
| || 10.50.252.24 fff-gw-m1 || 10.50.252.25 fff-has2 ||<br />
|-<br />
| || 10.50.252.26 fff-gw-m1 || 10.50.252.27 fff-wue1 ||<br />
|-<br />
| || 10.50.252.28 fff-bbg || 10.50.252.29 fff-nue1 ||<br />
|-<br />
| || 10.50.252.30 fff-bbg || 10.50.252.31 fff-ro1 ||<br />
|-<br />
| || 10.50.252.32 fff-bbg || 10.50.252.33 fff-has2 ||<br />
|-<br />
| || 10.50.252.34 fff-bbg || <font color="grey"> 10.50.252.35 (free) </font> ||<br />
|-<br />
| || 10.50.252.36 fff-wue1 || 10.50.252.37 fff-bbg ||<br />
|-<br />
| || 10.50.252.38 fff-gw-m1 || 10.50.252.39 ro1 ||<br />
|-<br />
| || 10.50.252.40 fff-gw-yaga || 10.50.252.41 ro1 ||<br />
|-<br />
| || 10.50.252.42 fff-gw-yaga || 10.50.252.43 nue1 ||<br />
|-<br />
| || 10.50.252.44 fff-roffl || 10.50.252.45 fff-has2 ||<br />
|-<br />
| || 10.50.252.46 fff-fra1 || 10.50.252.47 fff-bbg ||<br />
|-<br />
| || 10.50.252.48 fff-fra1 || <font color="grey"> 10.50.252.49 (free) </font> ||<br />
|-<br />
| || 10.50.252.50 fff-roffl || 10.50.252.51 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.52 fff-has2 || 10.50.252.53 <font color="grey"> (free) </font> ||<br />
|-<br />
| || 10.50.252.54 fff-has2 || 10.50.252.55 fff-fra1 ||<br />
|-<br />
| || 10.50.252.56 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.57 kwadronaut ||<br />
|-<br />
| || 10.50.252.58 fff-gw-m1 || 10.50.252.59 kwadronaut ||<br />
|-<br />
| || 10.50.252.60 fff-nue1 || 10.50.252.61 kwadronaut ||<br />
|-<br />
| || 10.50.252.62 ro1 || 10.50.252.63 kwadronaut ||<br />
|-<br />
| || 10.50.252.64 staufen || 10.50.252.65 kwadronaut ||<br />
|-<br />
| || 10.50.252.66 watzmann || 10.50.252.67 kwadronaut ||<br />
|-<br />
| || 10.50.252.68 kwadronaut || 10.50.252.69 yaga ||<br />
|-<br />
| || 10.50.252.70 fff-has || 10.50.252.71 nue1 ||<br />
|-<br />
| || 10.50.252.72 fff-has || 10.50.252.73 fff-wue1 ||<br />
|-<br />
| || 10.50.252.74 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.75 fff-dns-cd1 ||<br />
|-<br />
| || 10.50.252.76 fff-has || 10.50.252.77 fff-has1 ||<br />
|-<br />
| || 10.50.252.78 fff-roffl || 10.50.252.79 fff-has1 ||<br />
|-<br />
| || 10.50.252.80 fff-has2 || 10.50.252.81 fff-has1 ||<br />
|-<br />
| || 10.50.252.82 fff-has || 10.50.252.83 fff-has3 ||<br />
|-<br />
| || 10.50.252.84 fff-has2 || 10.50.252.85 fff-has3 ||<br />
|-<br />
| || 10.50.252.86 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.87 fff-dns-cd2 ||<br />
|-<br />
| || 10.50.252.88 ro1 || 10.50.252.89 fablabnbggw ||<br />
|-<br />
| || 10.50.252.90 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.91 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.92 fff-has || 10.50.252.93 fff-has2 ||<br />
|-<br />
| || 10.50.252.94 ro1 || 10.50.252.95 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.96 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.97 fff-gw-cd2 ||<br />
|-<br />
| || 10.50.252.98 fff-gw-cd2 || 10.50.252.99 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.100 fff-gw-cd2 || 10.50.252.101 has2 ||<br />
|-<br />
| || 10.50.252.102 fff-gw-cd2 || 10.50.252.103 fff-gw-m1 ||<br />
|-<br />
| || 10.50.252.104 fff-gw-cd2 || 10.50.252.105 fff-dns-cd1 ||<br />
|-<br />
| || 10.50.252.106 fff-fr1-arm || 10.50.252.107 ro1 ||<br />
|-<br />
| || 10.50.252.250 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.251 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.252 Testsystem von [[Benutzer:ChristianD]] || 10.50.252.253 Testsystem2 von [[Benutzer:ChristianD]] ||<br />
|-<br />
! 10.83.0.0/16 || free for tests ||<br />
|-<br />
| || <font color="grey">10.83.0.1 - 10.83.255.254</font> || <br />
|-<br />
|}<br />
<br />
== Statische IP-Adressen ==<br />
Dienste müssen Ihre IP-Adressen natürlich aus dem Subnetz beziehen, in welchem sie angeschlossen sind. Damit es keine Konflikte gibt, muss die IP-Adresse hier registriert werden.<br />
<br />
=== Default Hood ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.16.0 – 10.50.17.255 || || IP-Bereich Default Hood || <br />
|-<br />
| 10.50.16.2 || fff-nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.16.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.16.11 || c.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.21 || rns3.franken.ff || DNS PoC - Recursor #3 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.16.100 || netmon.freifunk-franken.de || || [[Server#si1|Details]]<br />
|-<br />
| 10.50.16.112 ||???.franken.ff || Raspberry Pi, Test owncloud, FTP || MartinS<br />
|-<br />
| 10.50.16.128 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.150 ||Diagnose ChristianD || Diagnose ChristianD || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.16.200 ||???.franken.ff || Fileserver || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.16.212 ||???.franken.ff || NAS, verschiedene Services || JomJom<br />
|-<br />
| 10.50.16.222 ||???.franken.ff || VM, mom. nur Test || pixelchrome<br />
|-<br />
| 10.50.17.112 ||???.franken.ff || Webserver, Tests || wolli112<br />
|}<br />
<br />
=== Hood Fürth ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.32.0 – 10.50.32.255 || || IP-Bereich Fürth Hood || <br />
|-<br />
| 10.50.32.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.32.3 || fff-uk1.freifunk-franken.de || || [[Server#fff-uk1|Details]]<br />
|-<br />
| 10.50.32.4 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|- <br />
| 10.50.32.5 || [[fff-nue2|fff-nue2-gw1]] || Gateway || [[Benutzer:RedDog|RedDog]] [[Benutzer:Mayosemmel|Mayosemmel]] [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.6 || frei || ||<br />
|- <br />
| <font color="grey"> 10.50.32.7 </font>||<font color="grey"> (frei) </font> || ||<br />
|-<br />
| 10.50.32.26 || Test-PI || Statische IP des RasPI für Testzwecke || [[Benutzer:Hobo|Hobo]] <br />
|-<br />
| 10.50.32.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.32.70 || NAT für priv. Netz || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.71 || testbridgeclient.bridge.fff.community || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.100 || MicroNAS || anonymous FTP (10GB) || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.101 || Wetterstation || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Daten bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.102 || Wetterkamera || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Bilder bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.108 || williams || privater PC || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.109 || Raspi || Raspi Server im Höffner || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.110 || - || - || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.111 || stmichael.bridge.ws13.fff.community || Nanobeam M5 Bridge als AP auf St. Michael Richtung DelphiN || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.112 || ws13.bridge.stmichael.fff.community || Nanobeam M5 Bridge als Client bei DelphiN. Richtung St. Michael || [[Benutzer:delphiN|delphiN]], [[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.113 || stmichael.bridge.hoeffner.fff.community || Bridge als AP auf St. Michael. Richtung Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.114 || hoeffner.bridge.stmichael.fff.community || Bridge als Client bei Hoeffner. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.115 || clockwork.bridge.stmichael.fff.community || Bridge als Client bei Clockwork. Richtung St. Michael || [[Benutzer:clockwork|clockwork]],[[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]], <br />
|-<br />
| 10.50.32.117 || || ToughSwitch Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.118 || || ToughSwitch auf WS13 || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.119 || || ToughSwitch auf StMichael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.120 || || ToughSwitch im Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.121 || || Bridge als AP auf St. Michael. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.122 || || Bridge als Client in Europaallee. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.123 || || Reserviert: Bridge als AP auf Hardhöhe. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.124 || || Bridge als Client in Europaallee. Richtung Hardhöhe || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.150 || ChristianD's PC || FFF-Netz ohne Internet || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.151 || feste Laptop IP || Für Speedtests mit manuellen Gateway || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.152 || RasPi || Testsystem || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.170 || HoeffnerPrinter || Drucker Computerraum Höffner || [[Benutzer:delphiN|delphiN]] <br />
|-<br />
| 10.50.32.199 || || Ralphs home-server ftp/http || [[Benutzer:dk5ras|dk5ras]] <br />
|}<br />
<br />
=== Hood Nürnberg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.40.0 – 10.50.40.255 || || IP-Bereich Nürnberg Hood || <br />
|-<br />
|<strike>10.50.40.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.40.6 || fff-bbg-tmp|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.7 || fff-gw-yaga|| || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.40.8 || fff-bbg|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.10 || FFF-GW-M1 || || [[Server#FFF-GW-M1|Details]]<br />
|-<br />
| 10.50.40.11 || a.ns.franken.ff || DNS PoC - Master || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.12 || b.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.20 || - – - || Direct Connect HUB || [[Benutzer:TheFroggy|TheFroggy]]<br />
|-<br />
| 10.50.40.21 || rns1.franken.ff || DNS PoC - Recursor #1 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.22 || rns2.franken.ff || DNS PoC - Recursor #2 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| <strike>10.50.40.40</strike> || <strike>fff-synology.freifunk-franken.de</strike> || Umgezogen nach NBGLand || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.40.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.40.51 || mayo-test.fff.community || || [[Benutzer:mayosemmel|mayosemmel]]<br />
|-<br />
| 10.50.40.52 || VPN ins FF || || [[Benutzer:mayosemmel|mayosemmel]]<br />
|-<br />
| 10.50.40.66 || flightradar.freifunk-franken.de || Dump1090 || [[Benutzer:Sixkiller6kl|sixkiller6kl]]<br />
|-<br />
| 10.50.40.88 || Knotenpunkt || Test-Server || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.98 || jabber.pm-ib.de || Jabber-Server || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.99 || K4CG || Dinge-Tester || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.100 || K4CG || Dinge-Tester || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.101 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.102 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.103 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.110 || ff_br_Spenglerstr || 5-GHz-Bridge Spenglerstr --> Johannis || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.111 || ff_Johannis || 5-GHz-Bridge Johannis --> Spenglerstr || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.120 || -- || 5-GHz-Access Point (Schniegling) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.121 || -- || 5-GHz-Client (Naturfreundehaus Nürnberg Mitte) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.122 || -- || 5-GHz-Client (Quelle GU) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.123 || -- || 5-GHz-AccessPoint (Quelle, Internetanbindung) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.130 || ff_nhgbr_Johnny || 5-GHz-Master (Standort Spenglerstr) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.131 || ff_nhgbr_NHG || 5-GHz-Slave (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.132 || ff_NHG_Osten || 5-GHz-Master (Standort Nachbarschaftshaus Goho, Richtung Osten) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.135 || ff_nhgswitch_NHG || POE-Switch (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.140 || ff_TS_PoE_tmp || 5-Port POE-Switch (für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.141 || ff_NS_M5_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.142 || ff_NS_M5_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.143 || ff_PB_5AC_500_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.144 || ff_PB_5AC_500_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.145 || ff_nhgbrsüd_M5loco_Master || 5-GHz-Master (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.146 || ff_Bauerngassebr_M5loco_Slave || 5-GHz-Slave (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.200 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Client, Routerfernwartung || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.206 || --- || lokale Dienste || [[Benutzer:meskal|meskal]]<br />
|-<br />
| 10.50.40.201 – 10.50.40.205|| Test || bitte vorläufig freihalten, danke || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.230 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.231 ||???.franken.ff || Juniper SRX (VRF) || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.232 ||???.franken.ff || Raspberry Pi || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.233 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.234 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
| 10.50.43.165 || fffsvr01.franken.freifunk.net || SMB, FTP Server 250GB || [[Benutzer:ManuelS|ManuelS]]<br />
|}<br />
<br />
=== Hood Ansbach ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.48.0 – 10.50.48.255 || || IP-Bereich Ansbach Hood || <br />
|-<br />
| 10.50.48.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.48.3 || fff-gw-cdfue1 || || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| 10.50.48.20 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.21 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.48.230 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.231 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.232 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.233 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.234 || || mom. nur Test || JuzeCr<br />
|}<br />
<br />
=== Hood Hassberge ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.56.0 – 10.50.56.255 || || IP-Bereich Hassberge Hood || <br />
|-<br />
| 10.50.56.1 || fff-has1|| || [[Server#fff-has1|Details]] <br />
|-<br />
| 10.50.56.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]] <br />
|-<br />
| 10.50.56.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.56.7 || fff-roffl|| || [[Server#fff-roffl|Details]]<br />
|-<br />
| 10.50.56.8 || fff-has3 || || [[Server#fff-has3|Details]] <br />
|-<br />
| 10.50.56.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| Bitte den Bereich 10.50.56.120 – 10.50.56.129 für [[Benutzer:Plocker|Plocker]] frei lassen<br />
|-<br />
| 10.50.56.123 || Teeworlds-Game-Server || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.124 || OwnCloud + Wiki || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.125 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.126 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.132 ||<strike> Webserver + MUD? || || [[Benutzer:PeterPhilipp|area52]]</strike><br />
|}<br />
<br />
=== Hood Hassberge Süd ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.60.0 – 10.50.60.255 || || IP-Bereich HassbergeSued Hood ||<br />
|-<br />
|<strike> 10.50.60.1</strike> || <strike>fff-has1 </strike>|| || [[Server#fff-has1|Details]]<br />
|-<br />
| 10.50.60.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.60.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.60.7 || fff-roffl|| || [[Server#fff-roffl|Details]] <br />
|-<br />
| 10.50.60.10 || Webcam Meehäusle Parkplatz|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.11 || Webcam Meehäusle Biergarten|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.100 /mediawiki || Webserver Mediawiki (in progress: Wikipedia(de)offline mirror)|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.101 /wiki || Raspi Webserver mit MediaWiki (Haßberge Wiki)|| || [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Erlangen ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.64.0 – 10.50.64.255 || || IP-Bereich Erlangen Hood || <br />
|-<br />
| 10.50.64.3 || fff-gw-yaga || || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.64.4 || fff-gw-kwadro || || [[Server#fff-gw-kwadro|Details]]<br />
|-<br />
| 10.50.64.10 || radiator.franken.ff || || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.11 || voip-1.radiator.franken.ff || Outernet, VoIP mittels SIP || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.12 || cam-1.radiator.franken.ff || IP-Cam || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.20 || radiatrix.franken.ff || geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.21 || cam-1.radiatrix.franken.ff || IP-Cam, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.22 || voip-1.radiatrix.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.30 || long.franken.ff || geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.31 || cam-1.long.franken.ff || IP-Cam || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.33 || voip-1.long.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.40 |||| Streaming Erlangen (im Aufbau) || [[Benutzer:R.funkt|R.funkt]]<br />
|-<br />
| 10.50.64.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.64.60 || gate3 || Dev || [[Benutzer:Jonas-bebe|Jonas-bebe]]<br />
|-<br />
| 10.50.64.70 |||| Raspi-Test || [[Benutzer:Dieter123|Dieter123]]<br />
|-<br />
| 10.50.64.78 |||| IP-CAM || [[Benutzer:moonrat|moonrat]]<br />
|-<br />
| 10.50.64.79 |||| IP-CAM || [[Benutzer:moonrat|moonrat]]<br />
|}<br />
<br />
=== Hood Würzburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.72.0 – 10.50.79.255 || || IP-Bereich Würzburg Hood || <br />
|-<br />
| 10.50.72.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.72.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.72.6 || fff-wue1|| || [[Server#fff-wue1|Details]] <br />
|-<br />
| 10.50.72.7 || kleeV2|| || [[Server#kleeV2|Details]] <br />
|-<br />
| 10.50.72.9 || Raspi-test|| || [[MisterCrumble|MisterCrumble]]<br />
|-<br />
| 10.50.72.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.72.72 || WikipediaClon || Soll ein Clon der Wikipedia werden. || [[Benutzer:Luensche|Luensche]]<br />
|-<br />
| 10.50.72.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood BGL ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.80.0 – 10.50.87.255 || || IP-Bereich BGL Hood || <br />
|-<br />
| 10.50.80.1 || watzmann || ||<br />
|-<br />
| 10.50.80.2 || staufen || ||<br />
|}<br />
<br />
=== Hood Nürnberger-Land ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.88.0 – 10.50.95.255 || || IP-Bereich NbgLand Hood || <br />
|-<br />
| 10.50.88.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.88.10 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.11 || fff-gw-cdnbgland2 || Gateway (Testbetrieb) || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.40 || fff-synology.freifunk-franken.de || Umzug nach Hood-Teilung || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.88.170 ||???.franken.ff || 5-GHz Richtfunk AP || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.171 ||???.franken.ff || 5-GHz Richtfunk Client || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.172 ||???.franken.ff || VM zum Testen || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood Aschaffenburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.96.0 – 10.50.103.255 || || IP-Bereich Aschaffenburg || <br />
|-<br />
| 10.50.96.x || fff-res|| || <br />
|-<br />
| 10.50.96.3 || fff-has || Gateway [[Server#fff-has|Details]]<br />
|| [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Hof ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.104.0 – 10.50.111.255 || || IP-Bereich Hof || <br />
|-<br />
| 10.50.104.1 || fff-has1 || Gateway [[Server#fff-has1|Details]]<br />
|| [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.104.2 || fff-fr1-arm || Gateway || [[User:RedDog]]<br />
|-<br />
| 10.50.104.10 || fff-gw-cdhof1 || Gateway || ChristianD<br />
|}<br />
<br />
=== Hood FabLabnbg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.132.0 – 10.50.134.255 || || IP-Bereich FabLabnbg || <br />
|-<br />
| 10.50.132.1 || fablab || Gateway FabLabnbg || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|-<br />
| 10.50.132.2 || Switch || Switch || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|-<br />
| 10.50.132.9 || Raspberry Pi || Für Alfredmaster || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.132.10 || 5GHz Test || 5GHz Test || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|}<br />
<br />
=== Hood Hardhöhe ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.130.0 – 10.50.131.255 || || IP-Bereich Hardhöhe || <br />
|-<br />
| 10.50.130.1 || fff-gw-hhd || Gateway Hardhöhedach || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.10 || fff-5g-hhd || Für eth1.3.10 am Gateway zum erreichen der 5GHz Geräte || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.11 || fff-5gs1-hhd || erste LBE-5AC-16-120 || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.12 || fff-5gs2-hhd || zweite LBE-5AC-16-120 || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|}<br />
<br />
=== Hood Aux ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
!10.50.240.1 – 10.50.247.254 || || IP-Bereich aux Hood || <br />
|-<br />
| 10.50.240.1 || fff-bbg || ||<br />
|-<br />
| 10.50.240.2 || fff-fra1 || ||<br />
|-<br />
| 10.50.240.3 || fff-gw-cdaux2 || ||<br />
|-<br />
| 10.50.240.20 || || Testgateway Flo für Hotel Busch |||<br />
|-<br />
| 10.50.240.11 || AP.bridge1.hoeffner.fff.community || Bridge AP Höffner || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.12 || S01.bridge1.hoeffner.fff.community || Bridge Station Hardhöhe || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.100 || fff-client-auxcd1 || Client zur Fernwartung aux || [[Benutzer:ChristianD|ChristianD]] ||<br />
|}<br />
<br />
= BSSID =<br />
<br />
{|<br />
! BSSID !! Hood !!<br />
|-<br />
| 00:ca:ff:ee:ba:be || legacy ||<br />
|-<br />
| ca:ff:ee:ba:be:00 || Trainstation ||<br />
|-<br />
| ca:ff:ee:ba:be:02 || Fürth || <br />
|-<br />
| ca:ff:ee:ba:be:03 || Nürnberg ||<br />
|-<br />
| ca:ff:ee:ba:be:04 || FabLabNbg ||<br />
|-<br />
| ca:ff:ee:ba:be:05 || Hardhöhe ||<br />
|}</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Portal:Netz&diff=6578
Portal:Netz
2016-05-15T07:08:54Z
<p>Green: /* Liste der Subnetze */</p>
<hr />
<div>== Das Netz ==<br />
Eine Karte der aktiven Router gibt es [https://monitoring.freifunk-franken.de/map].<br />
<br />
Eine Karte der Hoods ist [http://keyserver.freifunk-franken.de/fff/voronoimap.php hier] zu finden.<br />
<br />
Die [https://monitoring.freifunk-franken.de/routers Liste der Router] kann dank Monitoring immer live verfolgt werden. Infos über die Schreibweise (z.B. "/20") gibt es in der [http://de.wikipedia.org/wiki/CIDR Wikipedia].<br />
<br />
=== Gateway ===<br />
Erste Versuche einer sinnvollen Aufteilung von Gateways. Erweiterungen und Verbesserungen sind jederzeit erwünscht. [https://pad.freifunk.net/p/Gatewayaufteilung-Franken Zum Pad]<br />
<br />
== IP-Netz ==<br />
Mit der Netz-Umstellung vom 22.03.2014 haben wir nicht mehr länger ein großes [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_2_.E2.80.93_Sicherungsschicht_.28Data_Link_Layer.29 Layer-II-Netz], welches durch das [https://de.wikipedia.org/wiki/B.A.T.M.A.N. B.A.T.M.A.N. advanced]-Protokoll geroutet wird. Seitdem gibt es mehrere [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_3_.E2.80.93_Vermittlungsschicht_.28Network_Layer.29 Layer-III-Netze] (Hoods). Ein Layer-III-Netz entsteht grundsätzlich, indem hier ein Subnetz eingetragen wird. Wie dabei genau vorgegangen wird, steht in [[HoodVerwaltung]].<br />
Für jedes Subnetz muss separat abgewogen werden, wie groß es werden wird und wo es dann in die bestehenden Subnetze am besten eingegliedert werden kann.<br />
<br />
==== DHCP ====<br />
[[Datei:Hoods.png|200px|thumb|right|Vorschlag für die Hood-Organisation]]<br />
Damit simple Clients das neue Subnetz nutzen können, muss ein eigener DHCP-Server pro Subnetz bereit gestellt werden. Es macht dabei häufig Sinn, das Subnetz in IP-Bereiche aufzuteilen, die von mehreren DHCP-Servern verteilt werden. Ein zweiter DHCP-Server ermöglicht zum einen eine Lastverteilung, zum anderen erhöht sich die Ausfallsicherheit. Der DHCP-Server muss den Clients ein Default-Gateway und mindestens einen DNS-Server zuweisen. Da das Default-Gateway ebenfalls innerhalb des Subnetzes liegen muss, bietet es sich an, den selben Server, auf dem das DHCP läuft, zu nutzen.<br />
<br />
==== OLSR-Router ====<br />
Das Subnetz muss anschließend an das vorhandene Freifunknetz angeschlossen werden. Dazu muss eine Verbindung zu einem bestehenden OLSR-Router aufgebaut werden. Dies kann eine VPN-Verbindung, aber auch eine Wifi-Verbindung sein und muss individuell zwischen den zwei Parteien ausgehandelt werden. Es kann sinnvoll sein, Verbindungen zu mehr als einem OLSR-Router zu haben. Sobald der eigene Router an das OLSR-Netz angebunden ist, ist er selbst ein OLSR-Router.<br />
<br />
An den eigenen OLSR-Router können nun Accesspoints angeschlossen werden. Dies kann per VPN, WLAN, Kabel oder anderweitig geschehen. Es ist auch möglich, den Accesspoint selbst als OLSR-Router anzubinden. Auch diese Konfiguration ist individuell zu klären. Ein Accesspoint kann ein (oder mehrere) einfacher Wifi-AP oder auch ein Array von mehreren B.A.T.M.A.N.-Knoten sein. Es sollte vermieden werden, dass sich Subnetze vermischen. Dies würde immer dann passieren, wenn zwei Layer-II-Netze, die eigentlich unterschiedliche Subnetze verteilen, verbunden werden. Besonders beim B.A.T.M.A.N.-Protokoll besteht hier leicht diese Gefahr; daher sollte für jedes Subnetz eine eigene BSSID und ESSID gewählt werden.<br />
<br />
==== Aus Routersicht ====<br />
Nur Router in einer Hood können sich per B.A.T.M.A.N. advanced vermaschen, sowohl per VPN, also auch per WLAN. Daher müssen Router die räumlich nahe beieinander stehen auch in derselben Hood sein. Durch das Vermaschen des Netzes wird allerdings auch Verwaltungs-Verkehr erzeugt (Overhead). Je größer die Hood, desto größer der Overhead.<br />
<br />
Eine Verbindung zwischen Routern in unterschiedlichen Hoods ist per IP (OSI Schicht 3) möglich.<br />
<br />
Wenn im Netmon kein Standort eingegeben wurde, dann landet der Router in der Dafault-Hood.<br />
<br />
==== Monitoring (Netmon) ====<br />
Aktuell können sich Knoten nur über ein IPv6-Link-Local-Interface beim Netmon anmelden und Netmon kann die Knoten nur über eine IPv6-Link-Local-Adresse abfragen. Hier muss ein neuer Mechanismus gefunden werden, der es ermöglicht, die Knoten über Subnetze hinweg anzusprechen.<br />
<br />
Als Workaround ist es möglich, über einen Layer-II-Tunnel zum Netmon-Server das Subnetz an das Netmon anzubinden. Auf dem Netmon-Server werden alle Subnetze in einem Bridge-Interface zusammengefasst, welches keine Pakete weiterleiten kann.<br />
<br />
==== Wireless-LAN ====<br />
Wir haben uns auf folgende WLAN-Parameter verständigt:<br />
'''ESSID: franken.freifunk.net'''. Kanal 1.<br />
<br />
== Liste der Subnetze ==<br />
{|<br />
! !! Bereich !! Bereitgestellt durch<br />
|-<br />
! 10.50.0.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.0.1 – 10.50.15.254</font> || <br />
|-<br />
! 10.50.16.0/20 || Default Hood ||<br />
|-<br />
| || 10.50.16.1 – 10.50.17.255 || Statische Adressen<br />
|-<br />
| || 10.50.18.0 – 10.50.19.255 || --<br />
|-<br />
| || 10.50.20.0 – 10.50.21.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey">10.50.22.0 – 10.50.23.254 </font> || <br />
|-<br />
| || <font color="grey">10.50.24.0 – 10.50.31.254 </font> || <br />
|-<br />
! 10.50.32.0/21 || Fürth Hood ||<br />
|-<br />
| || 10.50.32.1 – 10.50.32.255 || Statische Adressen<br />
|-<br />
| || 10.50.33.0 – 10.50.34.255 || [[fff-nue2|fff-nue2-gw1]]<br />
|-<br />
| || 10.50.35.0 – 10.50.36.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey"> 10.50.37.0 – 10.50.37.255 </font> || --<br />
|-<br />
| || 10.50.38.0 – 10.50.39.254 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.40.0/21 || Nürnberg Hood ||<br />
|-<br />
| || 10.50.40.1 – 10.50.40.255 || Statische Adressen<br />
|-<br />
| || 10.50.41.0 – 10.50.42.255 || [[Server#FFF-GW-M1|FFF-GW-M1]]<br />
|-<br />
| || <font color="grey"> 10.50.43.0 - 10.50.43.255 </font> || <br />
|-<br />
| || 10.50.44.0 – 10.50.44.255 || (umgezogen) [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| ||10.50.45.0 – 10.50.46.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.47.0 – 10.50.47.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.48.0/21 || Ansbach Hood ||<br />
|-<br />
| || 10.50.48.1 – 10.50.48.255 || Statische Adressen<br />
|-<br />
| || 10.50.49.0 – 10.50.50.255 || <br />
|-<br />
| || 10.50.51.0 – 10.50.52.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.53.0 – 10.50.54.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| || <font color="grey">10.50.55.0 – 10.50.55.254</font> || <br />
|-<br />
! 10.50.56.0/22 || Hassberge Hood ||<br />
|-<br />
| || 10.50.56.1 – 10.50.56.255 || Statische Adressen<br />
|-<br />
| || 10.50.57.0 – 10.50.57.255 || [[Server#fff-has3|fff-has3]]<br />
|-<br />
| || 10.50.58.0 – 10.50.58.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.59.0 – 10.50.59.254 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
! 10.50.60.0/22 || HassbergeSued Hood ||<br />
|-<br />
| || 10.50.60.1 – 10.50.60.255 || Statische Adressen<br />
|-<br />
| || 10.50.61.0 – 10.50.61.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
| || 10.50.62.0 – 10.50.62.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.63.0 – 10.50.63.254 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
! 10.50.64.0/21 || Erlangen Hood ||<br />
|-<br />
| || 10.50.64.1 – 10.50.64.255 || Statische Adressen<br />
|-<br />
| || 10.50.65.0 – 10.50.66.255 || [[Server#fff-gw-kwadro|fff-gw-kwadro]]<br />
|-<br />
| || 10.50.67.0 – 10.50.68.255 || free<br />
|-<br />
| || 10.50.69.0 – 10.50.71.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.72.0/21 || Würzburg Hood ||<br />
|-<br />
| || 10.50.72.1 – 10.50.72.255 || Statische Adressen<br />
|-<br />
| || <font color="grey"> 10.50.73.0 – 10.50.74.255 </font>|| <br />
|-<br />
| || 10.50.75.0 – 10.50.76.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.77.0 – 10.50.78.255 || [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || 10.50.79.0 – 10.50.79.254 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
! 10.50.80.0/21 || BGL ||<br />
|-<br />
| || 10.50.80.1 – 10.50.80.255 || Statische Adressen<br />
|-<br />
| || 10.50.81.0 – 10.50.82.255 || [[Server#watzmann|watzmann]]<br />
|-<br />
| || 10.50.83.0 – 10.50.84.255 || [[Server#staufen|staufen]]<br />
|-<br />
! 10.50.88.0/21 || NbgLand Hood ||<br />
|-<br />
| || 10.50.88.1 – 10.50.88.255 || Statische Adressen<br />
|-<br />
| || 10.50.89.0 – 10.50.89.255 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| || 10.50.90.0 - 10.50.91.255 || fff-gw-cdnbgland2 (Testbetrieb)<br />
|-<br />
| || <font color="grey">10.50.92.0 - 10.50.93.255</font> || <br />
|-<br />
| || 10.50.94.0 – 10.50.95.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.96.0/21 || Aschaffenburg Hood ||<br />
|-<br />
| || 10.50.96.1 – 10.50.96.255 || Statische Adressen<br />
|-<br />
| || 10.50.97.1 – 10.50.97.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
! 10.50.104.0/21 || Hof Hood ||<br />
|-<br />
| || 10.50.104.1 – 10.50.104.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.105.0 - 10.50.106.255</font> || free<br />
|-<br />
| || 10.50.107.0 – 10.50.107.255 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
| || 10.50.108.0 - 10.50.109.255 || fff-fr1-arm<br />
|-<br />
| || 10.50.110.1 - 10.50.111.254 || fff-gw-cdhof1<br />
|-<br />
! 10.50.112.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.112.1 – 10.50.119.254</font> || <br />
|-<br />
! 10.50.120.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.120.1 – 10.50.127.254</font> || <br />
|-<br />
! 10.50.128.0/24 || Test von Casandro ||<br />
|-<br />
| || 10.50.128.20 – 10.50.128.200 || 10.50.128.1<br />
|-<br />
! 10.50.129.0/24 || free ||<br />
|-<br />
| || 10.50.129.0 || free<br />
|-<br />
! 10.50.130.0/23 || Hardhöhe ||<br />
|-<br />
| || 10.50.130.1 - 10.50.130.255 || Statische Adressen<br />
|-<br />
| || 10.50.131.0 – 10.50.131.127 || Gateway Hochhaus<br />
|-<br />
! 10.50.132.0/22 || FabLabNbg Hood ||<br />
|-<br />
| || 10.50.132.1 - 10.50.132.255 || Statische Adressen<br />
|-<br />
| || 10.50.133.0 – 10.50.133.255 || FabLabNbgGW<br />
|-<br />
| || 10.50.134.0 - 10.50.135.254 || frei<br />
|-<br />
! 10.50.136.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.136.1 – 10.50.143.254</font> || <br />
|-<br />
! 10.50.144.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.144.1 – 10.50.159.254</font> || <br />
|-<br />
! 10.50.160.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.160.1 – 10.50.191.254</font> || <br />
|-<br />
! 10.50.192.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.192.1 – 10.50.223.254</font> || <br />
|-<br />
! 10.50.224.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.224.1 – 10.50.239.254</font> || <br />
|-<br />
! 10.50.240.0/21 || fffaux ||<br />
|-<br />
| || 10.50.240.1 – 10.50.240.255 || Statische Adressen<br />
|-<br />
| || 10.50.241.0 – 10.50.241.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.242.0 – 10.50.243.255 || [[Server#fff-fra1|fff-fra1]]<br />
|-<br />
| || 10.50.244.0 – 10.50.244.127 || Testinstallation Busch (Flo)<br />
|-<br />
| || <font color="grey"> 10.50.244.128 - 10.50.245.255 </font> || | <font color="grey"> (free) </font><br />
|-<br />
| || 10.50.246.0 - 10.50.247.254 || fff-gw-cdaux2<br />
|-<br />
<br />
! 10.50.248.0/22 || free ||<br />
|-<br />
| || 10.50.248.1 – 10.50.248.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.249.0 - 10.50.251.254</font> || <br />
|-<br />
! 10.50.252.0/22 || TUNNEL ||<br />
|-<br />
| || 10.50.252.0 fff_ro1 || 10.50.252.1 nue1 || <br />
|-<br />
| || 10.50.252.2 fff_ro1 || 10.50.252.3 watzmann || <br />
|-<br />
| || 10.50.252.4 fff_ro1 || 10.50.252.5 staufen || <br />
|-<br />
| || 10.50.252.6 fff_ro1 || 10.50.252.7 has2 || <br />
|-<br />
| || 10.50.252.8 fff_ro1 || 10.50.252.9 has || <br />
|-<br />
| || 10.50.252.10 ro1 || 10.50.252.11 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.12 fff-has2 || 10.50.252.13 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.14 fff-gw-m1 || 10.50.252.15 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || <font color="grey"> 10.50.252.16 (free) </font>|| 10.50.252.17 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || <font color="grey"> 10.50.252.18 (free)</font> || 10.50.252.19 nue1 ||<br />
|-<br />
| || 10.50.252.20 <font color="grey"> (free) </font> || 10.50.252.21 ro1 ||<br />
|-<br />
| || 10.50.252.22 fff-gw-yaga || 10.50.252.23 fff-wue1 ||<br />
|-<br />
| || 10.50.252.24 fff-gw-m1 || 10.50.252.25 fff-has2 ||<br />
|-<br />
| || 10.50.252.26 fff-gw-m1 || 10.50.252.27 fff-wue1 ||<br />
|-<br />
| || 10.50.252.28 fff-bbg || 10.50.252.29 fff-nue1 ||<br />
|-<br />
| || 10.50.252.30 fff-bbg || 10.50.252.31 fff-ro1 ||<br />
|-<br />
| || 10.50.252.32 fff-bbg || 10.50.252.33 fff-has2 ||<br />
|-<br />
| || 10.50.252.34 fff-bbg || <font color="grey"> 10.50.252.35 (free) </font> ||<br />
|-<br />
| || 10.50.252.36 fff-wue1 || 10.50.252.37 fff-bbg ||<br />
|-<br />
| || 10.50.252.38 fff-gw-m1 || 10.50.252.39 ro1 ||<br />
|-<br />
| || 10.50.252.40 fff-gw-yaga || 10.50.252.41 ro1 ||<br />
|-<br />
| || 10.50.252.42 fff-gw-yaga || 10.50.252.43 nue1 ||<br />
|-<br />
| || 10.50.252.44 fff-roffl || 10.50.252.45 fff-has2 ||<br />
|-<br />
| || 10.50.252.46 fff-fra1 || 10.50.252.47 fff-bbg ||<br />
|-<br />
| || 10.50.252.48 fff-fra1 || <font color="grey"> 10.50.252.49 (free) </font> ||<br />
|-<br />
| || 10.50.252.50 fff-roffl || 10.50.252.51 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.52 fff-has2 || 10.50.252.53 <font color="grey"> (free) </font> ||<br />
|-<br />
| || 10.50.252.54 fff-has2 || 10.50.252.55 fff-fra1 ||<br />
|-<br />
| || 10.50.252.56 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.57 kwadronaut ||<br />
|-<br />
| || 10.50.252.58 fff-gw-m1 || 10.50.252.59 kwadronaut ||<br />
|-<br />
| || 10.50.252.60 fff-nue1 || 10.50.252.61 kwadronaut ||<br />
|-<br />
| || 10.50.252.62 ro1 || 10.50.252.63 kwadronaut ||<br />
|-<br />
| || 10.50.252.64 staufen || 10.50.252.65 kwadronaut ||<br />
|-<br />
| || 10.50.252.66 watzmann || 10.50.252.67 kwadronaut ||<br />
|-<br />
| || 10.50.252.68 kwadronaut || 10.50.252.69 yaga ||<br />
|-<br />
| || 10.50.252.70 fff-has || 10.50.252.71 nue1 ||<br />
|-<br />
| || 10.50.252.72 fff-has || 10.50.252.73 fff-wue1 ||<br />
|-<br />
| || 10.50.252.74 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.75 fff-dns-cd1 ||<br />
|-<br />
| || 10.50.252.76 fff-has || 10.50.252.77 fff-has1 ||<br />
|-<br />
| || 10.50.252.78 fff-roffl || 10.50.252.79 fff-has1 ||<br />
|-<br />
| || 10.50.252.80 fff-has2 || 10.50.252.81 fff-has1 ||<br />
|-<br />
| || 10.50.252.82 fff-has || 10.50.252.83 fff-has3 ||<br />
|-<br />
| || 10.50.252.84 fff-has2 || 10.50.252.85 fff-has3 ||<br />
|-<br />
| || 10.50.252.86 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.87 fff-dns-cd2 ||<br />
|-<br />
| || 10.50.252.88 ro1 || 10.50.252.89 fablabnbggw ||<br />
|-<br />
| || 10.50.252.90 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.91 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.92 fff-has || 10.50.252.93 fff-has2 ||<br />
|-<br />
| || 10.50.252.94 ro1 || 10.50.252.95 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.96 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.97 fff-gw-cd2 ||<br />
|-<br />
| || 10.50.252.98 fff-gw-cd2 || 10.50.252.99 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.100 fff-gw-cd2 || 10.50.252.101 has2 ||<br />
|-<br />
| || 10.50.252.102 fff-gw-cd2 || 10.50.252.103 fff-gw-m1 ||<br />
|-<br />
| || 10.50.252.104 fff-gw-cd2 || 10.50.252.105 fff-dns-cd1 ||<br />
|-<br />
| || 10.50.252.106 fff-fr1-arm || 10.50.252.107 ro1 ||<br />
|-<br />
| || 10.50.252.250 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.251 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.252 Testsystem von [[Benutzer:ChristianD]] || 10.50.252.253 Testsystem2 von [[Benutzer:ChristianD]] ||<br />
|-<br />
! 10.83.0.0/16 || free for tests ||<br />
|-<br />
| || <font color="grey">10.83.0.1 - 10.83.255.254</font> || <br />
|-<br />
|}<br />
<br />
== Statische IP-Adressen ==<br />
Dienste müssen Ihre IP-Adressen natürlich aus dem Subnetz beziehen, in welchem sie angeschlossen sind. Damit es keine Konflikte gibt, muss die IP-Adresse hier registriert werden.<br />
<br />
=== Default Hood ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.16.0 – 10.50.17.255 || || IP-Bereich Default Hood || <br />
|-<br />
| 10.50.16.2 || fff-nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.16.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.16.11 || c.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.21 || rns3.franken.ff || DNS PoC - Recursor #3 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.16.100 || netmon.freifunk-franken.de || || [[Server#si1|Details]]<br />
|-<br />
| 10.50.16.112 ||???.franken.ff || Raspberry Pi, Test owncloud, FTP || MartinS<br />
|-<br />
| 10.50.16.128 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.150 ||Diagnose ChristianD || Diagnose ChristianD || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.16.200 ||???.franken.ff || Fileserver || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.16.212 ||???.franken.ff || NAS, verschiedene Services || JomJom<br />
|-<br />
| 10.50.16.222 ||???.franken.ff || VM, mom. nur Test || pixelchrome<br />
|-<br />
| 10.50.17.112 ||???.franken.ff || Webserver, Tests || wolli112<br />
|}<br />
<br />
=== Hood Fürth ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.32.0 – 10.50.32.255 || || IP-Bereich Fürth Hood || <br />
|-<br />
| 10.50.32.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.32.3 || fff-uk1.freifunk-franken.de || || [[Server#fff-uk1|Details]]<br />
|-<br />
| 10.50.32.4 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|- <br />
| 10.50.32.5 || [[fff-nue2|fff-nue2-gw1]] || Gateway || [[Benutzer:RedDog|RedDog]] [[Benutzer:Mayosemmel|Mayosemmel]] [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.6 || frei || ||<br />
|- <br />
| <font color="grey"> 10.50.32.7 </font>||<font color="grey"> (frei) </font> || ||<br />
|-<br />
| 10.50.32.26 || Test-PI || Statische IP des RasPI für Testzwecke || [[Benutzer:Hobo|Hobo]] <br />
|-<br />
| 10.50.32.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.32.70 || NAT für priv. Netz || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.71 || testbridgeclient.bridge.fff.community || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.100 || MicroNAS || anonymous FTP (10GB) || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.101 || Wetterstation || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Daten bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.102 || Wetterkamera || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Bilder bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.108 || williams || privater PC || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.109 || Raspi || Raspi Server im Höffner || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.110 || - || - || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.111 || stmichael.bridge.ws13.fff.community || Nanobeam M5 Bridge als AP auf St. Michael Richtung DelphiN || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.112 || ws13.bridge.stmichael.fff.community || Nanobeam M5 Bridge als Client bei DelphiN. Richtung St. Michael || [[Benutzer:delphiN|delphiN]], [[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.113 || stmichael.bridge.hoeffner.fff.community || Bridge als AP auf St. Michael. Richtung Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.114 || hoeffner.bridge.stmichael.fff.community || Bridge als Client bei Hoeffner. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.115 || clockwork.bridge.stmichael.fff.community || Bridge als Client bei Clockwork. Richtung St. Michael || [[Benutzer:clockwork|clockwork]],[[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]], <br />
|-<br />
| 10.50.32.117 || || ToughSwitch Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.118 || || ToughSwitch auf WS13 || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.119 || || ToughSwitch auf StMichael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.120 || || ToughSwitch im Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.121 || || Bridge als AP auf St. Michael. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.122 || || Bridge als Client in Europaallee. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.123 || || Reserviert: Bridge als AP auf Hardhöhe. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.124 || || Bridge als Client in Europaallee. Richtung Hardhöhe || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.150 || ChristianD's PC || FFF-Netz ohne Internet || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.151 || feste Laptop IP || Für Speedtests mit manuellen Gateway || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.152 || RasPi || Testsystem || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.170 || HoeffnerPrinter || Drucker Computerraum Höffner || [[Benutzer:delphiN|delphiN]] <br />
|-<br />
| 10.50.32.199 || || Ralphs home-server ftp/http || [[Benutzer:dk5ras|dk5ras]] <br />
|}<br />
<br />
=== Hood Nürnberg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.40.0 – 10.50.40.255 || || IP-Bereich Nürnberg Hood || <br />
|-<br />
|<strike>10.50.40.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.40.6 || fff-bbg-tmp|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.7 || fff-gw-yaga|| || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.40.8 || fff-bbg|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.10 || FFF-GW-M1 || || [[Server#FFF-GW-M1|Details]]<br />
|-<br />
| 10.50.40.11 || a.ns.franken.ff || DNS PoC - Master || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.12 || b.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.20 || - – - || Direct Connect HUB || [[Benutzer:TheFroggy|TheFroggy]]<br />
|-<br />
| 10.50.40.21 || rns1.franken.ff || DNS PoC - Recursor #1 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.22 || rns2.franken.ff || DNS PoC - Recursor #2 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| <strike>10.50.40.40</strike> || <strike>fff-synology.freifunk-franken.de</strike> || Umgezogen nach NBGLand || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.40.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.40.51 || mayo-test.fff.community || || [[Benutzer:mayosemmel|mayosemmel]]<br />
|-<br />
| 10.50.40.52 || VPN ins FF || || [[Benutzer:mayosemmel|mayosemmel]]<br />
|-<br />
| 10.50.40.66 || flightradar.freifunk-franken.de || Dump1090 || [[Benutzer:Sixkiller6kl|sixkiller6kl]]<br />
|-<br />
| 10.50.40.88 || Knotenpunkt || Test-Server || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.98 || jabber.pm-ib.de || Jabber-Server || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.99 || K4CG || Dinge-Tester || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.100 || K4CG || Dinge-Tester || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.101 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.102 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.103 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.110 || ff_br_Spenglerstr || 5-GHz-Bridge Spenglerstr --> Johannis || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.111 || ff_Johannis || 5-GHz-Bridge Johannis --> Spenglerstr || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.120 || -- || 5-GHz-Access Point (Schniegling) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.121 || -- || 5-GHz-Client (Naturfreundehaus Nürnberg Mitte) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.122 || -- || 5-GHz-Client (Quelle GU) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.123 || -- || 5-GHz-AccessPoint (Quelle, Internetanbindung) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.130 || ff_nhgbr_Johnny || 5-GHz-Master (Standort Spenglerstr) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.131 || ff_nhgbr_NHG || 5-GHz-Slave (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.132 || ff_NHG_Osten || 5-GHz-Master (Standort Nachbarschaftshaus Goho, Richtung Osten) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.135 || ff_nhgswitch_NHG || POE-Switch (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.140 || ff_TS_PoE_tmp || 5-Port POE-Switch (für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.141 || ff_NS_M5_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.142 || ff_NS_M5_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.143 || ff_PB_5AC_500_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.144 || ff_PB_5AC_500_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.145 || ff_nhgbrsüd_M5loco_Master || 5-GHz-Master (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.146 || ff_Bauerngassebr_M5loco_Slave || 5-GHz-Slave (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.200 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Client, Routerfernwartung || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.206 || --- || lokale Dienste || [[Benutzer:meskal|meskal]]<br />
|-<br />
| 10.50.40.201 – 10.50.40.205|| Test || bitte vorläufig freihalten, danke || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.230 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.231 ||???.franken.ff || Juniper SRX (VRF) || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.232 ||???.franken.ff || Raspberry Pi || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.233 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.234 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
| 10.50.43.165 || fffsvr01.franken.freifunk.net || SMB, FTP Server 250GB || [[Benutzer:ManuelS|ManuelS]]<br />
|}<br />
<br />
=== Hood Ansbach ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.48.0 – 10.50.48.255 || || IP-Bereich Ansbach Hood || <br />
|-<br />
| 10.50.48.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.48.3 || fff-gw-cdfue1 || || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| 10.50.48.20 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.21 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.48.230 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.231 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.232 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.233 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.234 || || mom. nur Test || JuzeCr<br />
|}<br />
<br />
=== Hood Hassberge ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.56.0 – 10.50.56.255 || || IP-Bereich Hassberge Hood || <br />
|-<br />
| 10.50.56.1 || fff-has1|| || [[Server#fff-has1|Details]] <br />
|-<br />
| 10.50.56.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]] <br />
|-<br />
| 10.50.56.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.56.7 || fff-roffl|| || [[Server#fff-roffl|Details]]<br />
|-<br />
| 10.50.56.8 || fff-has3 || || [[Server#fff-has3|Details]] <br />
|-<br />
| 10.50.56.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| Bitte den Bereich 10.50.56.120 – 10.50.56.129 für [[Benutzer:Plocker|Plocker]] frei lassen<br />
|-<br />
| 10.50.56.123 || Teeworlds-Game-Server || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.124 || OwnCloud + Wiki || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.125 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.126 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.132 ||<strike> Webserver + MUD? || || [[Benutzer:PeterPhilipp|area52]]</strike><br />
|}<br />
<br />
=== Hood Hassberge Süd ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.60.0 – 10.50.60.255 || || IP-Bereich HassbergeSued Hood ||<br />
|-<br />
|<strike> 10.50.60.1</strike> || <strike>fff-has1 </strike>|| || [[Server#fff-has1|Details]]<br />
|-<br />
| 10.50.60.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.60.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.60.7 || fff-roffl|| || [[Server#fff-roffl|Details]] <br />
|-<br />
| 10.50.60.10 || Webcam Meehäusle Parkplatz|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.11 || Webcam Meehäusle Biergarten|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.100 /mediawiki || Webserver Mediawiki (in progress: Wikipedia(de)offline mirror)|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.101 /wiki || Raspi Webserver mit MediaWiki (Haßberge Wiki)|| || [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Erlangen ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.64.0 – 10.50.64.255 || || IP-Bereich Erlangen Hood || <br />
|-<br />
| 10.50.64.3 || fff-gw-yaga || || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.64.4 || fff-gw-kwadro || || [[Server#fff-gw-kwadro|Details]]<br />
|-<br />
| 10.50.64.10 || radiator.franken.ff || || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.11 || voip-1.radiator.franken.ff || Outernet, VoIP mittels SIP || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.12 || cam-1.radiator.franken.ff || IP-Cam || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.20 || radiatrix.franken.ff || geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.21 || cam-1.radiatrix.franken.ff || IP-Cam, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.22 || voip-1.radiatrix.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.30 || long.franken.ff || geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.31 || cam-1.long.franken.ff || IP-Cam || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.33 || voip-1.long.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.40 |||| Streaming Erlangen (im Aufbau) || [[Benutzer:R.funkt|R.funkt]]<br />
|-<br />
| 10.50.64.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.64.60 || gate3 || Dev || [[Benutzer:Jonas-bebe|Jonas-bebe]]<br />
|-<br />
| 10.50.64.70 |||| Raspi-Test || [[Benutzer:Dieter123|Dieter123]]<br />
|-<br />
| 10.50.64.78 |||| IP-CAM || [[Benutzer:moonrat|moonrat]]<br />
|-<br />
| 10.50.64.79 |||| IP-CAM || [[Benutzer:moonrat|moonrat]]<br />
|}<br />
<br />
=== Hood Würzburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.72.0 – 10.50.79.255 || || IP-Bereich Würzburg Hood || <br />
|-<br />
| 10.50.72.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.72.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.72.6 || fff-wue1|| || [[Server#fff-wue1|Details]] <br />
|-<br />
| 10.50.72.7 || kleeV2|| || [[Server#kleeV2|Details]] <br />
|-<br />
| 10.50.72.9 || Raspi-test|| || [[MisterCrumble|MisterCrumble]]<br />
|-<br />
| 10.50.72.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.72.72 || WikipediaClon || Soll ein Clon der Wikipedia werden. || [[Benutzer:Luensche|Luensche]]<br />
|-<br />
| 10.50.72.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood BGL ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.80.0 – 10.50.87.255 || || IP-Bereich BGL Hood || <br />
|-<br />
| 10.50.80.1 || watzmann || ||<br />
|-<br />
| 10.50.80.2 || staufen || ||<br />
|}<br />
<br />
=== Hood Nürnberger-Land ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.88.0 – 10.50.95.255 || || IP-Bereich NbgLand Hood || <br />
|-<br />
| 10.50.88.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.88.10 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.11 || fff-gw-cdnbgland2 || Gateway (Testbetrieb) || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.40 || fff-synology.freifunk-franken.de || Umzug nach Hood-Teilung || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.88.170 ||???.franken.ff || 5-GHz Richtfunk AP || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.171 ||???.franken.ff || 5-GHz Richtfunk Client || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.172 ||???.franken.ff || VM zum Testen || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood Aschaffenburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.96.0 – 10.50.103.255 || || IP-Bereich Aschaffenburg || <br />
|-<br />
| 10.50.96.x || fff-res|| || <br />
|-<br />
| 10.50.96.3 || fff-has || Gateway [[Server#fff-has|Details]]<br />
|| [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Hof ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.104.0 – 10.50.111.255 || || IP-Bereich Hof || <br />
|-<br />
| 10.50.104.1 || fff-has1 || Gateway [[Server#fff-has1|Details]]<br />
|| [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.104.2 || fff-fr1-arm || Gateway || [[User:RedDog]]<br />
|-<br />
| 10.50.104.10 || fff-gw-cdhof1 || Gateway || ChristianD<br />
|}<br />
<br />
=== Hood FabLabnbg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.132.0 – 10.50.134.255 || || IP-Bereich FabLabnbg || <br />
|-<br />
| 10.50.132.1 || fablab || Gateway FabLabnbg || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|-<br />
| 10.50.132.2 || Switch || Switch || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|-<br />
| 10.50.132.9 || Raspberry Pi || Für Alfredmaster || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.132.10 || 5GHz Test || 5GHz Test || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|}<br />
<br />
=== Hood Hardhöhe ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.130.0 – 10.50.131.255 || || IP-Bereich Hardhöhe || <br />
|-<br />
| 10.50.130.1 || fff-gw-hhd || Gateway Hardhöhedach || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.10 || fff-5g-hhd || Für eth1.3.10 am Gateway zum erreichen der 5GHz Geräte || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.11 || fff-5gs1-hhd || erste LBE-5AC-16-120 || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.12 || fff-5gs2-hhd || zweite LBE-5AC-16-120 || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|}<br />
<br />
=== Hood Aux ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
!10.50.240.1 – 10.50.247.254 || || IP-Bereich aux Hood || <br />
|-<br />
| 10.50.240.1 || fff-bbg || ||<br />
|-<br />
| 10.50.240.2 || fff-fra1 || ||<br />
|-<br />
| 10.50.240.3 || fff-gw-cdaux2 || ||<br />
|-<br />
| 10.50.240.7 || kleeV2 || ||<br />
|-<br />
| 10.50.240.20 || || Testgateway Flo für Hotel Busch |||<br />
|-<br />
| 10.50.240.11 || AP.bridge1.hoeffner.fff.community || Bridge AP Höffner || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.12 || S01.bridge1.hoeffner.fff.community || Bridge Station Hardhöhe || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.100 || fff-client-auxcd1 || Client zur Fernwartung aux || [[Benutzer:ChristianD|ChristianD]] ||<br />
|}<br />
<br />
= BSSID =<br />
<br />
{|<br />
! BSSID !! Hood !!<br />
|-<br />
| 00:ca:ff:ee:ba:be || legacy ||<br />
|-<br />
| ca:ff:ee:ba:be:00 || Trainstation ||<br />
|-<br />
| ca:ff:ee:ba:be:02 || Fürth || <br />
|-<br />
| ca:ff:ee:ba:be:03 || Nürnberg ||<br />
|-<br />
| ca:ff:ee:ba:be:04 || FabLabNbg ||<br />
|-<br />
| ca:ff:ee:ba:be:05 || Hardhöhe ||<br />
|}</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Portal:Netz&diff=6577
Portal:Netz
2016-05-15T07:03:10Z
<p>Green: /* Liste der Subnetze */</p>
<hr />
<div>== Das Netz ==<br />
Eine Karte der aktiven Router gibt es [https://monitoring.freifunk-franken.de/map].<br />
<br />
Eine Karte der Hoods ist [http://keyserver.freifunk-franken.de/fff/voronoimap.php hier] zu finden.<br />
<br />
Die [https://monitoring.freifunk-franken.de/routers Liste der Router] kann dank Monitoring immer live verfolgt werden. Infos über die Schreibweise (z.B. "/20") gibt es in der [http://de.wikipedia.org/wiki/CIDR Wikipedia].<br />
<br />
=== Gateway ===<br />
Erste Versuche einer sinnvollen Aufteilung von Gateways. Erweiterungen und Verbesserungen sind jederzeit erwünscht. [https://pad.freifunk.net/p/Gatewayaufteilung-Franken Zum Pad]<br />
<br />
== IP-Netz ==<br />
Mit der Netz-Umstellung vom 22.03.2014 haben wir nicht mehr länger ein großes [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_2_.E2.80.93_Sicherungsschicht_.28Data_Link_Layer.29 Layer-II-Netz], welches durch das [https://de.wikipedia.org/wiki/B.A.T.M.A.N. B.A.T.M.A.N. advanced]-Protokoll geroutet wird. Seitdem gibt es mehrere [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_3_.E2.80.93_Vermittlungsschicht_.28Network_Layer.29 Layer-III-Netze] (Hoods). Ein Layer-III-Netz entsteht grundsätzlich, indem hier ein Subnetz eingetragen wird. Wie dabei genau vorgegangen wird, steht in [[HoodVerwaltung]].<br />
Für jedes Subnetz muss separat abgewogen werden, wie groß es werden wird und wo es dann in die bestehenden Subnetze am besten eingegliedert werden kann.<br />
<br />
==== DHCP ====<br />
[[Datei:Hoods.png|200px|thumb|right|Vorschlag für die Hood-Organisation]]<br />
Damit simple Clients das neue Subnetz nutzen können, muss ein eigener DHCP-Server pro Subnetz bereit gestellt werden. Es macht dabei häufig Sinn, das Subnetz in IP-Bereiche aufzuteilen, die von mehreren DHCP-Servern verteilt werden. Ein zweiter DHCP-Server ermöglicht zum einen eine Lastverteilung, zum anderen erhöht sich die Ausfallsicherheit. Der DHCP-Server muss den Clients ein Default-Gateway und mindestens einen DNS-Server zuweisen. Da das Default-Gateway ebenfalls innerhalb des Subnetzes liegen muss, bietet es sich an, den selben Server, auf dem das DHCP läuft, zu nutzen.<br />
<br />
==== OLSR-Router ====<br />
Das Subnetz muss anschließend an das vorhandene Freifunknetz angeschlossen werden. Dazu muss eine Verbindung zu einem bestehenden OLSR-Router aufgebaut werden. Dies kann eine VPN-Verbindung, aber auch eine Wifi-Verbindung sein und muss individuell zwischen den zwei Parteien ausgehandelt werden. Es kann sinnvoll sein, Verbindungen zu mehr als einem OLSR-Router zu haben. Sobald der eigene Router an das OLSR-Netz angebunden ist, ist er selbst ein OLSR-Router.<br />
<br />
An den eigenen OLSR-Router können nun Accesspoints angeschlossen werden. Dies kann per VPN, WLAN, Kabel oder anderweitig geschehen. Es ist auch möglich, den Accesspoint selbst als OLSR-Router anzubinden. Auch diese Konfiguration ist individuell zu klären. Ein Accesspoint kann ein (oder mehrere) einfacher Wifi-AP oder auch ein Array von mehreren B.A.T.M.A.N.-Knoten sein. Es sollte vermieden werden, dass sich Subnetze vermischen. Dies würde immer dann passieren, wenn zwei Layer-II-Netze, die eigentlich unterschiedliche Subnetze verteilen, verbunden werden. Besonders beim B.A.T.M.A.N.-Protokoll besteht hier leicht diese Gefahr; daher sollte für jedes Subnetz eine eigene BSSID und ESSID gewählt werden.<br />
<br />
==== Aus Routersicht ====<br />
Nur Router in einer Hood können sich per B.A.T.M.A.N. advanced vermaschen, sowohl per VPN, also auch per WLAN. Daher müssen Router die räumlich nahe beieinander stehen auch in derselben Hood sein. Durch das Vermaschen des Netzes wird allerdings auch Verwaltungs-Verkehr erzeugt (Overhead). Je größer die Hood, desto größer der Overhead.<br />
<br />
Eine Verbindung zwischen Routern in unterschiedlichen Hoods ist per IP (OSI Schicht 3) möglich.<br />
<br />
Wenn im Netmon kein Standort eingegeben wurde, dann landet der Router in der Dafault-Hood.<br />
<br />
==== Monitoring (Netmon) ====<br />
Aktuell können sich Knoten nur über ein IPv6-Link-Local-Interface beim Netmon anmelden und Netmon kann die Knoten nur über eine IPv6-Link-Local-Adresse abfragen. Hier muss ein neuer Mechanismus gefunden werden, der es ermöglicht, die Knoten über Subnetze hinweg anzusprechen.<br />
<br />
Als Workaround ist es möglich, über einen Layer-II-Tunnel zum Netmon-Server das Subnetz an das Netmon anzubinden. Auf dem Netmon-Server werden alle Subnetze in einem Bridge-Interface zusammengefasst, welches keine Pakete weiterleiten kann.<br />
<br />
==== Wireless-LAN ====<br />
Wir haben uns auf folgende WLAN-Parameter verständigt:<br />
'''ESSID: franken.freifunk.net'''. Kanal 1.<br />
<br />
== Liste der Subnetze ==<br />
{|<br />
! !! Bereich !! Bereitgestellt durch<br />
|-<br />
! 10.50.0.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.0.1 – 10.50.15.254</font> || <br />
|-<br />
! 10.50.16.0/20 || Default Hood ||<br />
|-<br />
| || 10.50.16.1 – 10.50.17.255 || Statische Adressen<br />
|-<br />
| || 10.50.18.0 – 10.50.19.255 || --<br />
|-<br />
| || 10.50.20.0 – 10.50.21.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey">10.50.22.0 – 10.50.23.254 </font> || <br />
|-<br />
| || <font color="grey">10.50.24.0 – 10.50.31.254 </font> || <br />
|-<br />
! 10.50.32.0/21 || Fürth Hood ||<br />
|-<br />
| || 10.50.32.1 – 10.50.32.255 || Statische Adressen<br />
|-<br />
| || 10.50.33.0 – 10.50.34.255 || [[fff-nue2|fff-nue2-gw1]]<br />
|-<br />
| || 10.50.35.0 – 10.50.36.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey"> 10.50.37.0 – 10.50.37.255 </font> || --<br />
|-<br />
| || 10.50.38.0 – 10.50.39.254 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.40.0/21 || Nürnberg Hood ||<br />
|-<br />
| || 10.50.40.1 – 10.50.40.255 || Statische Adressen<br />
|-<br />
| || 10.50.41.0 – 10.50.42.255 || [[Server#FFF-GW-M1|FFF-GW-M1]]<br />
|-<br />
| || <font color="grey"> 10.50.43.0 - 10.50.43.255 </font> || <br />
|-<br />
| || 10.50.44.0 – 10.50.44.255 || (umgezogen) [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| ||10.50.45.0 – 10.50.46.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.47.0 – 10.50.47.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.48.0/21 || Ansbach Hood ||<br />
|-<br />
| || 10.50.48.1 – 10.50.48.255 || Statische Adressen<br />
|-<br />
| || 10.50.49.0 – 10.50.50.255 || <br />
|-<br />
| || 10.50.51.0 – 10.50.52.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.53.0 – 10.50.54.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| || <font color="grey">10.50.55.0 – 10.50.55.254</font> || <br />
|-<br />
! 10.50.56.0/22 || Hassberge Hood ||<br />
|-<br />
| || 10.50.56.1 – 10.50.56.255 || Statische Adressen<br />
|-<br />
| || 10.50.57.0 – 10.50.57.255 || [[Server#fff-has3|fff-has3]]<br />
|-<br />
| || 10.50.58.0 – 10.50.58.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.59.0 – 10.50.59.254 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
! 10.50.60.0/22 || HassbergeSued Hood ||<br />
|-<br />
| || 10.50.60.1 – 10.50.60.255 || Statische Adressen<br />
|-<br />
| || 10.50.61.0 – 10.50.61.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
| || 10.50.62.0 – 10.50.62.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.63.0 – 10.50.63.254 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
! 10.50.64.0/21 || Erlangen Hood ||<br />
|-<br />
| || 10.50.64.1 – 10.50.64.255 || Statische Adressen<br />
|-<br />
| || 10.50.65.0 – 10.50.66.255 || [[Server#fff-gw-kwadro|fff-gw-kwadro]]<br />
|-<br />
| || 10.50.67.0 – 10.50.68.255 || free<br />
|-<br />
| || 10.50.69.0 – 10.50.71.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.72.0/21 || Würzburg Hood ||<br />
|-<br />
| || 10.50.72.1 – 10.50.72.255 || Statische Adressen<br />
|-<br />
| || <font color="grey"> 10.50.73.0 – 10.50.74.255 </font>|| <br />
|-<br />
| || 10.50.75.0 – 10.50.76.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.77.0 – 10.50.78.255 || [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || 10.50.79.0 – 10.50.79.254 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
! 10.50.80.0/21 || BGL ||<br />
|-<br />
| || 10.50.80.1 – 10.50.80.255 || Statische Adressen<br />
|-<br />
| || 10.50.81.0 – 10.50.82.255 || [[Server#watzmann|watzmann]]<br />
|-<br />
| || 10.50.83.0 – 10.50.84.255 || [[Server#staufen|staufen]]<br />
|-<br />
! 10.50.88.0/21 || NbgLand Hood ||<br />
|-<br />
| || 10.50.88.1 – 10.50.88.255 || Statische Adressen<br />
|-<br />
| || 10.50.89.0 – 10.50.89.255 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| || 10.50.90.0 - 10.50.91.255 || fff-gw-cdnbgland2 (Testbetrieb)<br />
|-<br />
| || <font color="grey">10.50.92.0 - 10.50.93.255</font> || <br />
|-<br />
| || 10.50.94.0 – 10.50.95.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.96.0/21 || Aschaffenburg Hood ||<br />
|-<br />
| || 10.50.96.1 – 10.50.96.255 || Statische Adressen<br />
|-<br />
| || 10.50.97.1 – 10.50.97.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
! 10.50.104.0/21 || Hof Hood ||<br />
|-<br />
| || 10.50.104.1 – 10.50.104.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.105.0 - 10.50.106.255</font> || free<br />
|-<br />
| || 10.50.107.0 – 10.50.107.255 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
| || 10.50.108.0 - 10.50.109.255 || fff-fr1-arm<br />
|-<br />
| || 10.50.110.1 - 10.50.111.254 || fff-gw-cdhof1<br />
|-<br />
! 10.50.112.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.112.1 – 10.50.119.254</font> || <br />
|-<br />
! 10.50.120.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.120.1 – 10.50.127.254</font> || <br />
|-<br />
! 10.50.128.0/24 || Test von Casandro ||<br />
|-<br />
| || 10.50.128.20 – 10.50.128.200 || 10.50.128.1<br />
|-<br />
! 10.50.129.0/24 || free ||<br />
|-<br />
| || 10.50.129.0 || free<br />
|-<br />
! 10.50.130.0/23 || Hardhöhe ||<br />
|-<br />
| || 10.50.130.1 - 10.50.130.255 || Statische Adressen<br />
|-<br />
| || 10.50.131.0 – 10.50.131.127 || Gateway Hochhaus<br />
|-<br />
! 10.50.132.0/22 || FabLabNbg Hood ||<br />
|-<br />
| || 10.50.132.1 - 10.50.132.255 || Statische Adressen<br />
|-<br />
| || 10.50.133.0 – 10.50.133.255 || FabLabNbgGW<br />
|-<br />
| || 10.50.134.0 - 10.50.135.254 || frei<br />
|-<br />
! 10.50.136.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.136.1 – 10.50.143.254</font> || <br />
|-<br />
! 10.50.144.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.144.1 – 10.50.159.254</font> || <br />
|-<br />
! 10.50.160.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.160.1 – 10.50.191.254</font> || <br />
|-<br />
! 10.50.192.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.192.1 – 10.50.223.254</font> || <br />
|-<br />
! 10.50.224.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.224.1 – 10.50.239.254</font> || <br />
|-<br />
! 10.50.240.0/21 || fffaux ||<br />
|-<br />
| || 10.50.240.1 – 10.50.240.255 || Statische Adressen<br />
|-<br />
| || 10.50.241.0 – 10.50.241.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.242.0 – 10.50.243.255 || [[Server#fff-fra1|fff-fra1]]<br />
|-<br />
| || 10.50.244.0 – 10.50.244.127 || Testinstallation Busch (Flo)<br />
|-<br />
| || <font color="grey"> 10.50.244.128 - 10.50.245.255 || | (free)</font> <br />
|-<br />
| || 10.50.246.0 - 10.50.247.254 || fff-gw-cdaux2<br />
|-<br />
<br />
! 10.50.248.0/22 || free ||<br />
|-<br />
| || 10.50.248.1 – 10.50.248.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.249.0 - 10.50.251.254</font> || <br />
|-<br />
! 10.50.252.0/22 || TUNNEL ||<br />
|-<br />
| || 10.50.252.0 fff_ro1 || 10.50.252.1 nue1 || <br />
|-<br />
| || 10.50.252.2 fff_ro1 || 10.50.252.3 watzmann || <br />
|-<br />
| || 10.50.252.4 fff_ro1 || 10.50.252.5 staufen || <br />
|-<br />
| || 10.50.252.6 fff_ro1 || 10.50.252.7 has2 || <br />
|-<br />
| || 10.50.252.8 fff_ro1 || 10.50.252.9 has || <br />
|-<br />
| || 10.50.252.10 ro1 || 10.50.252.11 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.12 fff-has2 || 10.50.252.13 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.14 fff-gw-m1 || 10.50.252.15 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.16 KleeV2 || 10.50.252.17 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.18 KleeV2 || 10.50.252.19 nue1 ||<br />
|-<br />
| || 10.50.252.20 KleeV2 || 10.50.252.21 ro1 ||<br />
|-<br />
| || 10.50.252.22 fff-gw-yaga || 10.50.252.23 fff-wue1 ||<br />
|-<br />
| || 10.50.252.24 fff-gw-m1 || 10.50.252.25 fff-has2 ||<br />
|-<br />
| || 10.50.252.26 fff-gw-m1 || 10.50.252.27 fff-wue1 ||<br />
|-<br />
| || 10.50.252.28 fff-bbg || 10.50.252.29 fff-nue1 ||<br />
|-<br />
| || 10.50.252.30 fff-bbg || 10.50.252.31 fff-ro1 ||<br />
|-<br />
| || 10.50.252.32 fff-bbg || 10.50.252.33 fff-has2 ||<br />
|-<br />
| || 10.50.252.34 fff-bbg || 10.50.252.35 KleeV2 ||<br />
|-<br />
| || 10.50.252.36 fff-wue1 || 10.50.252.37 fff-bbg ||<br />
|-<br />
| || 10.50.252.38 fff-gw-m1 || 10.50.252.39 ro1 ||<br />
|-<br />
| || 10.50.252.40 fff-gw-yaga || 10.50.252.41 ro1 ||<br />
|-<br />
| || 10.50.252.42 fff-gw-yaga || 10.50.252.43 nue1 ||<br />
|-<br />
| || 10.50.252.44 fff-roffl || 10.50.252.45 fff-has2 ||<br />
|-<br />
| || 10.50.252.46 fff-fra1 || 10.50.252.47 fff-bbg ||<br />
|-<br />
| || 10.50.252.48 fff-fra1 || 10.50.252.49 kleeV2 ||<br />
|-<br />
| || 10.50.252.50 fff-roffl || 10.50.252.51 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.52 fff-has2 || 10.50.252.53 kleeV2 ||<br />
|-<br />
| || 10.50.252.54 fff-has2 || 10.50.252.55 fff-fra1 ||<br />
|-<br />
| || 10.50.252.56 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.57 kwadronaut ||<br />
|-<br />
| || 10.50.252.58 fff-gw-m1 || 10.50.252.59 kwadronaut ||<br />
|-<br />
| || 10.50.252.60 fff-nue1 || 10.50.252.61 kwadronaut ||<br />
|-<br />
| || 10.50.252.62 ro1 || 10.50.252.63 kwadronaut ||<br />
|-<br />
| || 10.50.252.64 staufen || 10.50.252.65 kwadronaut ||<br />
|-<br />
| || 10.50.252.66 watzmann || 10.50.252.67 kwadronaut ||<br />
|-<br />
| || 10.50.252.68 kwadronaut || 10.50.252.69 yaga ||<br />
|-<br />
| || 10.50.252.70 fff-has || 10.50.252.71 nue1 ||<br />
|-<br />
| || 10.50.252.72 fff-has || 10.50.252.73 fff-wue1 ||<br />
|-<br />
| || 10.50.252.74 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.75 fff-dns-cd1 ||<br />
|-<br />
| || 10.50.252.76 fff-has || 10.50.252.77 fff-has1 ||<br />
|-<br />
| || 10.50.252.78 fff-roffl || 10.50.252.79 fff-has1 ||<br />
|-<br />
| || 10.50.252.80 fff-has2 || 10.50.252.81 fff-has1 ||<br />
|-<br />
| || 10.50.252.82 fff-has || 10.50.252.83 fff-has3 ||<br />
|-<br />
| || 10.50.252.84 fff-has2 || 10.50.252.85 fff-has3 ||<br />
|-<br />
| || 10.50.252.86 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.87 fff-dns-cd2 ||<br />
|-<br />
| || 10.50.252.88 ro1 || 10.50.252.89 fablabnbggw ||<br />
|-<br />
| || 10.50.252.90 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.91 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.92 fff-has || 10.50.252.93 fff-has2 ||<br />
|-<br />
| || 10.50.252.94 ro1 || 10.50.252.95 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.96 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.97 fff-gw-cd2 ||<br />
|-<br />
| || 10.50.252.98 fff-gw-cd2 || 10.50.252.99 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.100 fff-gw-cd2 || 10.50.252.101 has2 ||<br />
|-<br />
| || 10.50.252.102 fff-gw-cd2 || 10.50.252.103 fff-gw-m1 ||<br />
|-<br />
| || 10.50.252.104 fff-gw-cd2 || 10.50.252.105 fff-dns-cd1 ||<br />
|-<br />
| || 10.50.252.106 fff-fr1-arm || 10.50.252.107 ro1 ||<br />
|-<br />
| || 10.50.252.250 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.251 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.252 Testsystem von [[Benutzer:ChristianD]] || 10.50.252.253 Testsystem2 von [[Benutzer:ChristianD]] ||<br />
|-<br />
! 10.83.0.0/16 || free for tests ||<br />
|-<br />
| || <font color="grey">10.83.0.1 - 10.83.255.254</font> || <br />
|-<br />
|}<br />
<br />
== Statische IP-Adressen ==<br />
Dienste müssen Ihre IP-Adressen natürlich aus dem Subnetz beziehen, in welchem sie angeschlossen sind. Damit es keine Konflikte gibt, muss die IP-Adresse hier registriert werden.<br />
<br />
=== Default Hood ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.16.0 – 10.50.17.255 || || IP-Bereich Default Hood || <br />
|-<br />
| 10.50.16.2 || fff-nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.16.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.16.11 || c.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.21 || rns3.franken.ff || DNS PoC - Recursor #3 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.16.100 || netmon.freifunk-franken.de || || [[Server#si1|Details]]<br />
|-<br />
| 10.50.16.112 ||???.franken.ff || Raspberry Pi, Test owncloud, FTP || MartinS<br />
|-<br />
| 10.50.16.128 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.150 ||Diagnose ChristianD || Diagnose ChristianD || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.16.200 ||???.franken.ff || Fileserver || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.16.212 ||???.franken.ff || NAS, verschiedene Services || JomJom<br />
|-<br />
| 10.50.16.222 ||???.franken.ff || VM, mom. nur Test || pixelchrome<br />
|-<br />
| 10.50.17.112 ||???.franken.ff || Webserver, Tests || wolli112<br />
|}<br />
<br />
=== Hood Fürth ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.32.0 – 10.50.32.255 || || IP-Bereich Fürth Hood || <br />
|-<br />
| 10.50.32.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.32.3 || fff-uk1.freifunk-franken.de || || [[Server#fff-uk1|Details]]<br />
|-<br />
| 10.50.32.4 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|- <br />
| 10.50.32.5 || [[fff-nue2|fff-nue2-gw1]] || Gateway || [[Benutzer:RedDog|RedDog]] [[Benutzer:Mayosemmel|Mayosemmel]] [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.6 || frei || ||<br />
|- <br />
| <font color="grey"> 10.50.32.7 </font>||<font color="grey"> (frei) </font> || ||<br />
|-<br />
| 10.50.32.26 || Test-PI || Statische IP des RasPI für Testzwecke || [[Benutzer:Hobo|Hobo]] <br />
|-<br />
| 10.50.32.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.32.70 || NAT für priv. Netz || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.71 || testbridgeclient.bridge.fff.community || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.100 || MicroNAS || anonymous FTP (10GB) || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.101 || Wetterstation || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Daten bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.102 || Wetterkamera || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Bilder bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.108 || williams || privater PC || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.109 || Raspi || Raspi Server im Höffner || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.110 || - || - || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.111 || stmichael.bridge.ws13.fff.community || Nanobeam M5 Bridge als AP auf St. Michael Richtung DelphiN || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.112 || ws13.bridge.stmichael.fff.community || Nanobeam M5 Bridge als Client bei DelphiN. Richtung St. Michael || [[Benutzer:delphiN|delphiN]], [[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.113 || stmichael.bridge.hoeffner.fff.community || Bridge als AP auf St. Michael. Richtung Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.114 || hoeffner.bridge.stmichael.fff.community || Bridge als Client bei Hoeffner. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.115 || clockwork.bridge.stmichael.fff.community || Bridge als Client bei Clockwork. Richtung St. Michael || [[Benutzer:clockwork|clockwork]],[[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]], <br />
|-<br />
| 10.50.32.117 || || ToughSwitch Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.118 || || ToughSwitch auf WS13 || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.119 || || ToughSwitch auf StMichael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.120 || || ToughSwitch im Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.121 || || Bridge als AP auf St. Michael. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.122 || || Bridge als Client in Europaallee. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.123 || || Reserviert: Bridge als AP auf Hardhöhe. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.124 || || Bridge als Client in Europaallee. Richtung Hardhöhe || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.150 || ChristianD's PC || FFF-Netz ohne Internet || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.151 || feste Laptop IP || Für Speedtests mit manuellen Gateway || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.152 || RasPi || Testsystem || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.170 || HoeffnerPrinter || Drucker Computerraum Höffner || [[Benutzer:delphiN|delphiN]] <br />
|-<br />
| 10.50.32.199 || || Ralphs home-server ftp/http || [[Benutzer:dk5ras|dk5ras]] <br />
|}<br />
<br />
=== Hood Nürnberg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.40.0 – 10.50.40.255 || || IP-Bereich Nürnberg Hood || <br />
|-<br />
|<strike>10.50.40.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.40.6 || fff-bbg-tmp|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.7 || fff-gw-yaga|| || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.40.8 || fff-bbg|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.10 || FFF-GW-M1 || || [[Server#FFF-GW-M1|Details]]<br />
|-<br />
| 10.50.40.11 || a.ns.franken.ff || DNS PoC - Master || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.12 || b.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.20 || - – - || Direct Connect HUB || [[Benutzer:TheFroggy|TheFroggy]]<br />
|-<br />
| 10.50.40.21 || rns1.franken.ff || DNS PoC - Recursor #1 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.22 || rns2.franken.ff || DNS PoC - Recursor #2 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| <strike>10.50.40.40</strike> || <strike>fff-synology.freifunk-franken.de</strike> || Umgezogen nach NBGLand || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.40.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.40.51 || mayo-test.fff.community || || [[Benutzer:mayosemmel|mayosemmel]]<br />
|-<br />
| 10.50.40.52 || VPN ins FF || || [[Benutzer:mayosemmel|mayosemmel]]<br />
|-<br />
| 10.50.40.66 || flightradar.freifunk-franken.de || Dump1090 || [[Benutzer:Sixkiller6kl|sixkiller6kl]]<br />
|-<br />
| 10.50.40.88 || Knotenpunkt || Test-Server || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.98 || jabber.pm-ib.de || Jabber-Server || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.99 || K4CG || Dinge-Tester || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.100 || K4CG || Dinge-Tester || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.101 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.102 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.103 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.110 || ff_br_Spenglerstr || 5-GHz-Bridge Spenglerstr --> Johannis || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.111 || ff_Johannis || 5-GHz-Bridge Johannis --> Spenglerstr || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.120 || -- || 5-GHz-Access Point (Schniegling) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.121 || -- || 5-GHz-Client (Naturfreundehaus Nürnberg Mitte) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.122 || -- || 5-GHz-Client (Quelle GU) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.123 || -- || 5-GHz-AccessPoint (Quelle, Internetanbindung) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.130 || ff_nhgbr_Johnny || 5-GHz-Master (Standort Spenglerstr) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.131 || ff_nhgbr_NHG || 5-GHz-Slave (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.132 || ff_NHG_Osten || 5-GHz-Master (Standort Nachbarschaftshaus Goho, Richtung Osten) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.135 || ff_nhgswitch_NHG || POE-Switch (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.140 || ff_TS_PoE_tmp || 5-Port POE-Switch (für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.141 || ff_NS_M5_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.142 || ff_NS_M5_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.143 || ff_PB_5AC_500_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.144 || ff_PB_5AC_500_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.145 || ff_nhgbrsüd_M5loco_Master || 5-GHz-Master (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.146 || ff_Bauerngassebr_M5loco_Slave || 5-GHz-Slave (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.200 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Client, Routerfernwartung || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.206 || --- || lokale Dienste || [[Benutzer:meskal|meskal]]<br />
|-<br />
| 10.50.40.201 – 10.50.40.205|| Test || bitte vorläufig freihalten, danke || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.230 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.231 ||???.franken.ff || Juniper SRX (VRF) || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.232 ||???.franken.ff || Raspberry Pi || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.233 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.234 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
| 10.50.43.165 || fffsvr01.franken.freifunk.net || SMB, FTP Server 250GB || [[Benutzer:ManuelS|ManuelS]]<br />
|}<br />
<br />
=== Hood Ansbach ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.48.0 – 10.50.48.255 || || IP-Bereich Ansbach Hood || <br />
|-<br />
| 10.50.48.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.48.3 || fff-gw-cdfue1 || || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| 10.50.48.20 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.21 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.48.230 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.231 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.232 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.233 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.234 || || mom. nur Test || JuzeCr<br />
|}<br />
<br />
=== Hood Hassberge ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.56.0 – 10.50.56.255 || || IP-Bereich Hassberge Hood || <br />
|-<br />
| 10.50.56.1 || fff-has1|| || [[Server#fff-has1|Details]] <br />
|-<br />
| 10.50.56.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]] <br />
|-<br />
| 10.50.56.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.56.7 || fff-roffl|| || [[Server#fff-roffl|Details]]<br />
|-<br />
| 10.50.56.8 || fff-has3 || || [[Server#fff-has3|Details]] <br />
|-<br />
| 10.50.56.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| Bitte den Bereich 10.50.56.120 – 10.50.56.129 für [[Benutzer:Plocker|Plocker]] frei lassen<br />
|-<br />
| 10.50.56.123 || Teeworlds-Game-Server || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.124 || OwnCloud + Wiki || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.125 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.126 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.132 ||<strike> Webserver + MUD? || || [[Benutzer:PeterPhilipp|area52]]</strike><br />
|}<br />
<br />
=== Hood Hassberge Süd ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.60.0 – 10.50.60.255 || || IP-Bereich HassbergeSued Hood ||<br />
|-<br />
|<strike> 10.50.60.1</strike> || <strike>fff-has1 </strike>|| || [[Server#fff-has1|Details]]<br />
|-<br />
| 10.50.60.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.60.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.60.7 || fff-roffl|| || [[Server#fff-roffl|Details]] <br />
|-<br />
| 10.50.60.10 || Webcam Meehäusle Parkplatz|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.11 || Webcam Meehäusle Biergarten|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.100 /mediawiki || Webserver Mediawiki (in progress: Wikipedia(de)offline mirror)|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.101 /wiki || Raspi Webserver mit MediaWiki (Haßberge Wiki)|| || [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Erlangen ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.64.0 – 10.50.64.255 || || IP-Bereich Erlangen Hood || <br />
|-<br />
| 10.50.64.3 || fff-gw-yaga || || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.64.4 || fff-gw-kwadro || || [[Server#fff-gw-kwadro|Details]]<br />
|-<br />
| 10.50.64.10 || radiator.franken.ff || || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.11 || voip-1.radiator.franken.ff || Outernet, VoIP mittels SIP || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.12 || cam-1.radiator.franken.ff || IP-Cam || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.20 || radiatrix.franken.ff || geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.21 || cam-1.radiatrix.franken.ff || IP-Cam, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.22 || voip-1.radiatrix.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.30 || long.franken.ff || geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.31 || cam-1.long.franken.ff || IP-Cam || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.33 || voip-1.long.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.40 |||| Streaming Erlangen (im Aufbau) || [[Benutzer:R.funkt|R.funkt]]<br />
|-<br />
| 10.50.64.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.64.60 || gate3 || Dev || [[Benutzer:Jonas-bebe|Jonas-bebe]]<br />
|-<br />
| 10.50.64.70 |||| Raspi-Test || [[Benutzer:Dieter123|Dieter123]]<br />
|-<br />
| 10.50.64.78 |||| IP-CAM || [[Benutzer:moonrat|moonrat]]<br />
|-<br />
| 10.50.64.79 |||| IP-CAM || [[Benutzer:moonrat|moonrat]]<br />
|}<br />
<br />
=== Hood Würzburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.72.0 – 10.50.79.255 || || IP-Bereich Würzburg Hood || <br />
|-<br />
| 10.50.72.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.72.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.72.6 || fff-wue1|| || [[Server#fff-wue1|Details]] <br />
|-<br />
| 10.50.72.7 || kleeV2|| || [[Server#kleeV2|Details]] <br />
|-<br />
| 10.50.72.9 || Raspi-test|| || [[MisterCrumble|MisterCrumble]]<br />
|-<br />
| 10.50.72.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.72.72 || WikipediaClon || Soll ein Clon der Wikipedia werden. || [[Benutzer:Luensche|Luensche]]<br />
|-<br />
| 10.50.72.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood BGL ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.80.0 – 10.50.87.255 || || IP-Bereich BGL Hood || <br />
|-<br />
| 10.50.80.1 || watzmann || ||<br />
|-<br />
| 10.50.80.2 || staufen || ||<br />
|}<br />
<br />
=== Hood Nürnberger-Land ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.88.0 – 10.50.95.255 || || IP-Bereich NbgLand Hood || <br />
|-<br />
| 10.50.88.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.88.10 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.11 || fff-gw-cdnbgland2 || Gateway (Testbetrieb) || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.40 || fff-synology.freifunk-franken.de || Umzug nach Hood-Teilung || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.88.170 ||???.franken.ff || 5-GHz Richtfunk AP || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.171 ||???.franken.ff || 5-GHz Richtfunk Client || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.172 ||???.franken.ff || VM zum Testen || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood Aschaffenburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.96.0 – 10.50.103.255 || || IP-Bereich Aschaffenburg || <br />
|-<br />
| 10.50.96.x || fff-res|| || <br />
|-<br />
| 10.50.96.3 || fff-has || Gateway [[Server#fff-has|Details]]<br />
|| [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Hof ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.104.0 – 10.50.111.255 || || IP-Bereich Hof || <br />
|-<br />
| 10.50.104.1 || fff-has1 || Gateway [[Server#fff-has1|Details]]<br />
|| [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.104.2 || fff-fr1-arm || Gateway || [[User:RedDog]]<br />
|-<br />
| 10.50.104.10 || fff-gw-cdhof1 || Gateway || ChristianD<br />
|}<br />
<br />
=== Hood FabLabnbg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.132.0 – 10.50.134.255 || || IP-Bereich FabLabnbg || <br />
|-<br />
| 10.50.132.1 || fablab || Gateway FabLabnbg || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|-<br />
| 10.50.132.2 || Switch || Switch || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|-<br />
| 10.50.132.9 || Raspberry Pi || Für Alfredmaster || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.132.10 || 5GHz Test || 5GHz Test || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|}<br />
<br />
=== Hood Hardhöhe ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.130.0 – 10.50.131.255 || || IP-Bereich Hardhöhe || <br />
|-<br />
| 10.50.130.1 || fff-gw-hhd || Gateway Hardhöhedach || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.10 || fff-5g-hhd || Für eth1.3.10 am Gateway zum erreichen der 5GHz Geräte || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.11 || fff-5gs1-hhd || erste LBE-5AC-16-120 || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.12 || fff-5gs2-hhd || zweite LBE-5AC-16-120 || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|}<br />
<br />
=== Hood Aux ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
!10.50.240.1 – 10.50.247.254 || || IP-Bereich aux Hood || <br />
|-<br />
| 10.50.240.1 || fff-bbg || ||<br />
|-<br />
| 10.50.240.2 || fff-fra1 || ||<br />
|-<br />
| 10.50.240.3 || fff-gw-cdaux2 || ||<br />
|-<br />
| 10.50.240.7 || kleeV2 || ||<br />
|-<br />
| 10.50.240.20 || || Testgateway Flo für Hotel Busch |||<br />
|-<br />
| 10.50.240.11 || AP.bridge1.hoeffner.fff.community || Bridge AP Höffner || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.12 || S01.bridge1.hoeffner.fff.community || Bridge Station Hardhöhe || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.100 || fff-client-auxcd1 || Client zur Fernwartung aux || [[Benutzer:ChristianD|ChristianD]] ||<br />
|}<br />
<br />
= BSSID =<br />
<br />
{|<br />
! BSSID !! Hood !!<br />
|-<br />
| 00:ca:ff:ee:ba:be || legacy ||<br />
|-<br />
| ca:ff:ee:ba:be:00 || Trainstation ||<br />
|-<br />
| ca:ff:ee:ba:be:02 || Fürth || <br />
|-<br />
| ca:ff:ee:ba:be:03 || Nürnberg ||<br />
|-<br />
| ca:ff:ee:ba:be:04 || FabLabNbg ||<br />
|-<br />
| ca:ff:ee:ba:be:05 || Hardhöhe ||<br />
|}</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Portal:Netz&diff=6576
Portal:Netz
2016-05-15T06:54:55Z
<p>Green: /* Liste der Subnetze */</p>
<hr />
<div>== Das Netz ==<br />
Eine Karte der aktiven Router gibt es [https://monitoring.freifunk-franken.de/map].<br />
<br />
Eine Karte der Hoods ist [http://keyserver.freifunk-franken.de/fff/voronoimap.php hier] zu finden.<br />
<br />
Die [https://monitoring.freifunk-franken.de/routers Liste der Router] kann dank Monitoring immer live verfolgt werden. Infos über die Schreibweise (z.B. "/20") gibt es in der [http://de.wikipedia.org/wiki/CIDR Wikipedia].<br />
<br />
=== Gateway ===<br />
Erste Versuche einer sinnvollen Aufteilung von Gateways. Erweiterungen und Verbesserungen sind jederzeit erwünscht. [https://pad.freifunk.net/p/Gatewayaufteilung-Franken Zum Pad]<br />
<br />
== IP-Netz ==<br />
Mit der Netz-Umstellung vom 22.03.2014 haben wir nicht mehr länger ein großes [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_2_.E2.80.93_Sicherungsschicht_.28Data_Link_Layer.29 Layer-II-Netz], welches durch das [https://de.wikipedia.org/wiki/B.A.T.M.A.N. B.A.T.M.A.N. advanced]-Protokoll geroutet wird. Seitdem gibt es mehrere [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_3_.E2.80.93_Vermittlungsschicht_.28Network_Layer.29 Layer-III-Netze] (Hoods). Ein Layer-III-Netz entsteht grundsätzlich, indem hier ein Subnetz eingetragen wird. Wie dabei genau vorgegangen wird, steht in [[HoodVerwaltung]].<br />
Für jedes Subnetz muss separat abgewogen werden, wie groß es werden wird und wo es dann in die bestehenden Subnetze am besten eingegliedert werden kann.<br />
<br />
==== DHCP ====<br />
[[Datei:Hoods.png|200px|thumb|right|Vorschlag für die Hood-Organisation]]<br />
Damit simple Clients das neue Subnetz nutzen können, muss ein eigener DHCP-Server pro Subnetz bereit gestellt werden. Es macht dabei häufig Sinn, das Subnetz in IP-Bereiche aufzuteilen, die von mehreren DHCP-Servern verteilt werden. Ein zweiter DHCP-Server ermöglicht zum einen eine Lastverteilung, zum anderen erhöht sich die Ausfallsicherheit. Der DHCP-Server muss den Clients ein Default-Gateway und mindestens einen DNS-Server zuweisen. Da das Default-Gateway ebenfalls innerhalb des Subnetzes liegen muss, bietet es sich an, den selben Server, auf dem das DHCP läuft, zu nutzen.<br />
<br />
==== OLSR-Router ====<br />
Das Subnetz muss anschließend an das vorhandene Freifunknetz angeschlossen werden. Dazu muss eine Verbindung zu einem bestehenden OLSR-Router aufgebaut werden. Dies kann eine VPN-Verbindung, aber auch eine Wifi-Verbindung sein und muss individuell zwischen den zwei Parteien ausgehandelt werden. Es kann sinnvoll sein, Verbindungen zu mehr als einem OLSR-Router zu haben. Sobald der eigene Router an das OLSR-Netz angebunden ist, ist er selbst ein OLSR-Router.<br />
<br />
An den eigenen OLSR-Router können nun Accesspoints angeschlossen werden. Dies kann per VPN, WLAN, Kabel oder anderweitig geschehen. Es ist auch möglich, den Accesspoint selbst als OLSR-Router anzubinden. Auch diese Konfiguration ist individuell zu klären. Ein Accesspoint kann ein (oder mehrere) einfacher Wifi-AP oder auch ein Array von mehreren B.A.T.M.A.N.-Knoten sein. Es sollte vermieden werden, dass sich Subnetze vermischen. Dies würde immer dann passieren, wenn zwei Layer-II-Netze, die eigentlich unterschiedliche Subnetze verteilen, verbunden werden. Besonders beim B.A.T.M.A.N.-Protokoll besteht hier leicht diese Gefahr; daher sollte für jedes Subnetz eine eigene BSSID und ESSID gewählt werden.<br />
<br />
==== Aus Routersicht ====<br />
Nur Router in einer Hood können sich per B.A.T.M.A.N. advanced vermaschen, sowohl per VPN, also auch per WLAN. Daher müssen Router die räumlich nahe beieinander stehen auch in derselben Hood sein. Durch das Vermaschen des Netzes wird allerdings auch Verwaltungs-Verkehr erzeugt (Overhead). Je größer die Hood, desto größer der Overhead.<br />
<br />
Eine Verbindung zwischen Routern in unterschiedlichen Hoods ist per IP (OSI Schicht 3) möglich.<br />
<br />
Wenn im Netmon kein Standort eingegeben wurde, dann landet der Router in der Dafault-Hood.<br />
<br />
==== Monitoring (Netmon) ====<br />
Aktuell können sich Knoten nur über ein IPv6-Link-Local-Interface beim Netmon anmelden und Netmon kann die Knoten nur über eine IPv6-Link-Local-Adresse abfragen. Hier muss ein neuer Mechanismus gefunden werden, der es ermöglicht, die Knoten über Subnetze hinweg anzusprechen.<br />
<br />
Als Workaround ist es möglich, über einen Layer-II-Tunnel zum Netmon-Server das Subnetz an das Netmon anzubinden. Auf dem Netmon-Server werden alle Subnetze in einem Bridge-Interface zusammengefasst, welches keine Pakete weiterleiten kann.<br />
<br />
==== Wireless-LAN ====<br />
Wir haben uns auf folgende WLAN-Parameter verständigt:<br />
'''ESSID: franken.freifunk.net'''. Kanal 1.<br />
<br />
== Liste der Subnetze ==<br />
{|<br />
! !! Bereich !! Bereitgestellt durch<br />
|-<br />
! 10.50.0.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.0.1 – 10.50.15.254</font> || <br />
|-<br />
! 10.50.16.0/20 || Default Hood ||<br />
|-<br />
| || 10.50.16.1 – 10.50.17.255 || Statische Adressen<br />
|-<br />
| || 10.50.18.0 – 10.50.19.255 || --<br />
|-<br />
| || 10.50.20.0 – 10.50.21.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey">10.50.22.0 – 10.50.23.254 </font> || <br />
|-<br />
| || <font color="grey">10.50.24.0 – 10.50.31.254 </font> || <br />
|-<br />
! 10.50.32.0/21 || Fürth Hood ||<br />
|-<br />
| || 10.50.32.1 – 10.50.32.255 || Statische Adressen<br />
|-<br />
| || 10.50.33.0 – 10.50.34.255 || [[fff-nue2|fff-nue2-gw1]]<br />
|-<br />
| || 10.50.35.0 – 10.50.36.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey"> 10.50.37.0 – 10.50.37.255 </font> || --<br />
|-<br />
| || 10.50.38.0 – 10.50.39.254 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.40.0/21 || Nürnberg Hood ||<br />
|-<br />
| || 10.50.40.1 – 10.50.40.255 || Statische Adressen<br />
|-<br />
| || 10.50.41.0 – 10.50.42.255 || [[Server#FFF-GW-M1|FFF-GW-M1]]<br />
|-<br />
| || <font color="grey"> 10.50.43.0 - 10.50.43.255 </font> || <br />
|-<br />
| || 10.50.44.0 – 10.50.44.255 || (umgezogen) [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| ||10.50.45.0 – 10.50.46.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.47.0 – 10.50.47.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.48.0/21 || Ansbach Hood ||<br />
|-<br />
| || 10.50.48.1 – 10.50.48.255 || Statische Adressen<br />
|-<br />
| || 10.50.49.0 – 10.50.50.255 || <br />
|-<br />
| || 10.50.51.0 – 10.50.52.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.53.0 – 10.50.54.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| || <font color="grey">10.50.55.0 – 10.50.55.254</font> || <br />
|-<br />
! 10.50.56.0/22 || Hassberge Hood ||<br />
|-<br />
| || 10.50.56.1 – 10.50.56.255 || Statische Adressen<br />
|-<br />
| || 10.50.57.0 – 10.50.57.255 || [[Server#fff-has3|fff-has3]]<br />
|-<br />
| || 10.50.58.0 – 10.50.58.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.59.0 – 10.50.59.254 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
! 10.50.60.0/22 || HassbergeSued Hood ||<br />
|-<br />
| || 10.50.60.1 – 10.50.60.255 || Statische Adressen<br />
|-<br />
| || 10.50.61.0 – 10.50.61.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
| || 10.50.62.0 – 10.50.62.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.63.0 – 10.50.63.254 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
! 10.50.64.0/21 || Erlangen Hood ||<br />
|-<br />
| || 10.50.64.1 – 10.50.64.255 || Statische Adressen<br />
|-<br />
| || 10.50.65.0 – 10.50.66.255 || [[Server#fff-gw-kwadro|fff-gw-kwadro]]<br />
|-<br />
| || 10.50.67.0 – 10.50.68.255 || free<br />
|-<br />
| || 10.50.69.0 – 10.50.71.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.72.0/21 || Würzburg Hood ||<br />
|-<br />
| || 10.50.72.1 – 10.50.72.255 || Statische Adressen<br />
|-<br />
| || <font color="grey"> 10.50.73.0 – 10.50.74.255 </font>|| <br />
|-<br />
| || 10.50.75.0 – 10.50.76.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.77.0 – 10.50.78.255 || [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || 10.50.79.0 – 10.50.79.254 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
! 10.50.80.0/21 || BGL ||<br />
|-<br />
| || 10.50.80.1 – 10.50.80.255 || Statische Adressen<br />
|-<br />
| || 10.50.81.0 – 10.50.82.255 || [[Server#watzmann|watzmann]]<br />
|-<br />
| || 10.50.83.0 – 10.50.84.255 || [[Server#staufen|staufen]]<br />
|-<br />
! 10.50.88.0/21 || NbgLand Hood ||<br />
|-<br />
| || 10.50.88.1 – 10.50.88.255 || Statische Adressen<br />
|-<br />
| || 10.50.89.0 – 10.50.89.255 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| || 10.50.90.0 - 10.50.91.255 || fff-gw-cdnbgland2 (Testbetrieb)<br />
|-<br />
| || <font color="grey">10.50.92.0 - 10.50.93.255</font> || <br />
|-<br />
| || 10.50.94.0 – 10.50.95.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.96.0/21 || Aschaffenburg Hood ||<br />
|-<br />
| || 10.50.96.1 – 10.50.96.255 || Statische Adressen<br />
|-<br />
| || 10.50.97.1 – 10.50.97.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
! 10.50.104.0/21 || Hof Hood ||<br />
|-<br />
| || 10.50.104.1 – 10.50.104.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.105.0 - 10.50.106.255</font> || free<br />
|-<br />
| || 10.50.107.0 – 10.50.107.255 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
| || 10.50.108.0 - 10.50.109.255 || fff-fr1-arm<br />
|-<br />
| || 10.50.110.1 - 10.50.111.254 || fff-gw-cdhof1<br />
|-<br />
! 10.50.112.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.112.1 – 10.50.119.254</font> || <br />
|-<br />
! 10.50.120.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.120.1 – 10.50.127.254</font> || <br />
|-<br />
! 10.50.128.0/24 || Test von Casandro ||<br />
|-<br />
| || 10.50.128.20 – 10.50.128.200 || 10.50.128.1<br />
|-<br />
! 10.50.129.0/24 || free ||<br />
|-<br />
| || 10.50.129.0 || free<br />
|-<br />
! 10.50.130.0/23 || Hardhöhe ||<br />
|-<br />
| || 10.50.130.1 - 10.50.130.255 || Statische Adressen<br />
|-<br />
| || 10.50.131.0 – 10.50.131.127 || Gateway Hochhaus<br />
|-<br />
! 10.50.132.0/22 || FabLabNbg Hood ||<br />
|-<br />
| || 10.50.132.1 - 10.50.132.255 || Statische Adressen<br />
|-<br />
| || 10.50.133.0 – 10.50.133.255 || FabLabNbgGW<br />
|-<br />
| || 10.50.134.0 - 10.50.135.254 || frei<br />
|-<br />
! 10.50.136.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.136.1 – 10.50.143.254</font> || <br />
|-<br />
! 10.50.144.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.144.1 – 10.50.159.254</font> || <br />
|-<br />
! 10.50.160.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.160.1 – 10.50.191.254</font> || <br />
|-<br />
! 10.50.192.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.192.1 – 10.50.223.254</font> || <br />
|-<br />
! 10.50.224.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.224.1 – 10.50.239.254</font> || <br />
|-<br />
! 10.50.240.0/21 || fffaux ||<br />
|-<br />
| || 10.50.240.1 – 10.50.240.255 || Statische Adressen<br />
|-<br />
| || 10.50.241.0 – 10.50.241.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.242.0 – 10.50.243.255 || [[Server#fff-fra1|fff-fra1]]<br />
|-<br />
| || 10.50.244.0 – 10.50.244.127 || Testinstallation Busch (Flo)<br />
|-<br />
| || 10.50.244.128 - 10.50.245.255 || | <font color="grey"> (free)</font> <br />
|-<br />
| || 10.50.246.0 - 10.50.247.254 || fff-gw-cdaux2<br />
|-<br />
<br />
! 10.50.248.0/22 || free ||<br />
|-<br />
| || 10.50.248.1 – 10.50.248.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.249.0 - 10.50.251.254</font> || <br />
|-<br />
! 10.50.252.0/22 || TUNNEL ||<br />
|-<br />
| || 10.50.252.0 fff_ro1 || 10.50.252.1 nue1 || <br />
|-<br />
| || 10.50.252.2 fff_ro1 || 10.50.252.3 watzmann || <br />
|-<br />
| || 10.50.252.4 fff_ro1 || 10.50.252.5 staufen || <br />
|-<br />
| || 10.50.252.6 fff_ro1 || 10.50.252.7 has2 || <br />
|-<br />
| || 10.50.252.8 fff_ro1 || 10.50.252.9 has || <br />
|-<br />
| || 10.50.252.10 ro1 || 10.50.252.11 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.12 fff-has2 || 10.50.252.13 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.14 fff-gw-m1 || 10.50.252.15 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.16 KleeV2 || 10.50.252.17 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.18 KleeV2 || 10.50.252.19 nue1 ||<br />
|-<br />
| || 10.50.252.20 KleeV2 || 10.50.252.21 ro1 ||<br />
|-<br />
| || 10.50.252.22 fff-gw-yaga || 10.50.252.23 fff-wue1 ||<br />
|-<br />
| || 10.50.252.24 fff-gw-m1 || 10.50.252.25 fff-has2 ||<br />
|-<br />
| || 10.50.252.26 fff-gw-m1 || 10.50.252.27 fff-wue1 ||<br />
|-<br />
| || 10.50.252.28 fff-bbg || 10.50.252.29 fff-nue1 ||<br />
|-<br />
| || 10.50.252.30 fff-bbg || 10.50.252.31 fff-ro1 ||<br />
|-<br />
| || 10.50.252.32 fff-bbg || 10.50.252.33 fff-has2 ||<br />
|-<br />
| || 10.50.252.34 fff-bbg || 10.50.252.35 KleeV2 ||<br />
|-<br />
| || 10.50.252.36 fff-wue1 || 10.50.252.37 fff-bbg ||<br />
|-<br />
| || 10.50.252.38 fff-gw-m1 || 10.50.252.39 ro1 ||<br />
|-<br />
| || 10.50.252.40 fff-gw-yaga || 10.50.252.41 ro1 ||<br />
|-<br />
| || 10.50.252.42 fff-gw-yaga || 10.50.252.43 nue1 ||<br />
|-<br />
| || 10.50.252.44 fff-roffl || 10.50.252.45 fff-has2 ||<br />
|-<br />
| || 10.50.252.46 fff-fra1 || 10.50.252.47 fff-bbg ||<br />
|-<br />
| || 10.50.252.48 fff-fra1 || 10.50.252.49 kleeV2 ||<br />
|-<br />
| || 10.50.252.50 fff-roffl || 10.50.252.51 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.52 fff-has2 || 10.50.252.53 kleeV2 ||<br />
|-<br />
| || 10.50.252.54 fff-has2 || 10.50.252.55 fff-fra1 ||<br />
|-<br />
| || 10.50.252.56 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.57 kwadronaut ||<br />
|-<br />
| || 10.50.252.58 fff-gw-m1 || 10.50.252.59 kwadronaut ||<br />
|-<br />
| || 10.50.252.60 fff-nue1 || 10.50.252.61 kwadronaut ||<br />
|-<br />
| || 10.50.252.62 ro1 || 10.50.252.63 kwadronaut ||<br />
|-<br />
| || 10.50.252.64 staufen || 10.50.252.65 kwadronaut ||<br />
|-<br />
| || 10.50.252.66 watzmann || 10.50.252.67 kwadronaut ||<br />
|-<br />
| || 10.50.252.68 kwadronaut || 10.50.252.69 yaga ||<br />
|-<br />
| || 10.50.252.70 fff-has || 10.50.252.71 nue1 ||<br />
|-<br />
| || 10.50.252.72 fff-has || 10.50.252.73 fff-wue1 ||<br />
|-<br />
| || 10.50.252.74 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.75 fff-dns-cd1 ||<br />
|-<br />
| || 10.50.252.76 fff-has || 10.50.252.77 fff-has1 ||<br />
|-<br />
| || 10.50.252.78 fff-roffl || 10.50.252.79 fff-has1 ||<br />
|-<br />
| || 10.50.252.80 fff-has2 || 10.50.252.81 fff-has1 ||<br />
|-<br />
| || 10.50.252.82 fff-has || 10.50.252.83 fff-has3 ||<br />
|-<br />
| || 10.50.252.84 fff-has2 || 10.50.252.85 fff-has3 ||<br />
|-<br />
| || 10.50.252.86 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.87 fff-dns-cd2 ||<br />
|-<br />
| || 10.50.252.88 ro1 || 10.50.252.89 fablabnbggw ||<br />
|-<br />
| || 10.50.252.90 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.91 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.92 fff-has || 10.50.252.93 fff-has2 ||<br />
|-<br />
| || 10.50.252.94 ro1 || 10.50.252.95 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.96 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.97 fff-gw-cd2 ||<br />
|-<br />
| || 10.50.252.98 fff-gw-cd2 || 10.50.252.99 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.100 fff-gw-cd2 || 10.50.252.101 has2 ||<br />
|-<br />
| || 10.50.252.102 fff-gw-cd2 || 10.50.252.103 fff-gw-m1 ||<br />
|-<br />
| || 10.50.252.104 fff-gw-cd2 || 10.50.252.105 fff-dns-cd1 ||<br />
|-<br />
| || 10.50.252.106 fff-fr1-arm || 10.50.252.107 ro1 ||<br />
|-<br />
| || 10.50.252.250 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.251 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.252 Testsystem von [[Benutzer:ChristianD]] || 10.50.252.253 Testsystem2 von [[Benutzer:ChristianD]] ||<br />
|-<br />
! 10.83.0.0/16 || free for tests ||<br />
|-<br />
| || <font color="grey">10.83.0.1 - 10.83.255.254</font> || <br />
|-<br />
|}<br />
<br />
== Statische IP-Adressen ==<br />
Dienste müssen Ihre IP-Adressen natürlich aus dem Subnetz beziehen, in welchem sie angeschlossen sind. Damit es keine Konflikte gibt, muss die IP-Adresse hier registriert werden.<br />
<br />
=== Default Hood ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.16.0 – 10.50.17.255 || || IP-Bereich Default Hood || <br />
|-<br />
| 10.50.16.2 || fff-nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.16.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.16.11 || c.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.21 || rns3.franken.ff || DNS PoC - Recursor #3 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.16.100 || netmon.freifunk-franken.de || || [[Server#si1|Details]]<br />
|-<br />
| 10.50.16.112 ||???.franken.ff || Raspberry Pi, Test owncloud, FTP || MartinS<br />
|-<br />
| 10.50.16.128 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.150 ||Diagnose ChristianD || Diagnose ChristianD || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.16.200 ||???.franken.ff || Fileserver || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.16.212 ||???.franken.ff || NAS, verschiedene Services || JomJom<br />
|-<br />
| 10.50.16.222 ||???.franken.ff || VM, mom. nur Test || pixelchrome<br />
|-<br />
| 10.50.17.112 ||???.franken.ff || Webserver, Tests || wolli112<br />
|}<br />
<br />
=== Hood Fürth ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.32.0 – 10.50.32.255 || || IP-Bereich Fürth Hood || <br />
|-<br />
| 10.50.32.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.32.3 || fff-uk1.freifunk-franken.de || || [[Server#fff-uk1|Details]]<br />
|-<br />
| 10.50.32.4 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|- <br />
| 10.50.32.5 || [[fff-nue2|fff-nue2-gw1]] || Gateway || [[Benutzer:RedDog|RedDog]] [[Benutzer:Mayosemmel|Mayosemmel]] [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.6 || frei || ||<br />
|- <br />
| <font color="grey"> 10.50.32.7 </font>||<font color="grey"> (frei) </font> || ||<br />
|-<br />
| 10.50.32.26 || Test-PI || Statische IP des RasPI für Testzwecke || [[Benutzer:Hobo|Hobo]] <br />
|-<br />
| 10.50.32.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.32.70 || NAT für priv. Netz || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.71 || testbridgeclient.bridge.fff.community || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.100 || MicroNAS || anonymous FTP (10GB) || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.101 || Wetterstation || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Daten bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.102 || Wetterkamera || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Bilder bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.108 || williams || privater PC || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.109 || Raspi || Raspi Server im Höffner || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.110 || - || - || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.111 || stmichael.bridge.ws13.fff.community || Nanobeam M5 Bridge als AP auf St. Michael Richtung DelphiN || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.112 || ws13.bridge.stmichael.fff.community || Nanobeam M5 Bridge als Client bei DelphiN. Richtung St. Michael || [[Benutzer:delphiN|delphiN]], [[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.113 || stmichael.bridge.hoeffner.fff.community || Bridge als AP auf St. Michael. Richtung Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.114 || hoeffner.bridge.stmichael.fff.community || Bridge als Client bei Hoeffner. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.115 || clockwork.bridge.stmichael.fff.community || Bridge als Client bei Clockwork. Richtung St. Michael || [[Benutzer:clockwork|clockwork]],[[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]], <br />
|-<br />
| 10.50.32.117 || || ToughSwitch Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.118 || || ToughSwitch auf WS13 || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.119 || || ToughSwitch auf StMichael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.120 || || ToughSwitch im Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.121 || || Bridge als AP auf St. Michael. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.122 || || Bridge als Client in Europaallee. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.123 || || Reserviert: Bridge als AP auf Hardhöhe. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.124 || || Bridge als Client in Europaallee. Richtung Hardhöhe || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.150 || ChristianD's PC || FFF-Netz ohne Internet || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.151 || feste Laptop IP || Für Speedtests mit manuellen Gateway || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.152 || RasPi || Testsystem || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.170 || HoeffnerPrinter || Drucker Computerraum Höffner || [[Benutzer:delphiN|delphiN]] <br />
|-<br />
| 10.50.32.199 || || Ralphs home-server ftp/http || [[Benutzer:dk5ras|dk5ras]] <br />
|}<br />
<br />
=== Hood Nürnberg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.40.0 – 10.50.40.255 || || IP-Bereich Nürnberg Hood || <br />
|-<br />
|<strike>10.50.40.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.40.6 || fff-bbg-tmp|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.7 || fff-gw-yaga|| || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.40.8 || fff-bbg|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.10 || FFF-GW-M1 || || [[Server#FFF-GW-M1|Details]]<br />
|-<br />
| 10.50.40.11 || a.ns.franken.ff || DNS PoC - Master || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.12 || b.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.20 || - – - || Direct Connect HUB || [[Benutzer:TheFroggy|TheFroggy]]<br />
|-<br />
| 10.50.40.21 || rns1.franken.ff || DNS PoC - Recursor #1 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.22 || rns2.franken.ff || DNS PoC - Recursor #2 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| <strike>10.50.40.40</strike> || <strike>fff-synology.freifunk-franken.de</strike> || Umgezogen nach NBGLand || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.40.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.40.51 || mayo-test.fff.community || || [[Benutzer:mayosemmel|mayosemmel]]<br />
|-<br />
| 10.50.40.52 || VPN ins FF || || [[Benutzer:mayosemmel|mayosemmel]]<br />
|-<br />
| 10.50.40.66 || flightradar.freifunk-franken.de || Dump1090 || [[Benutzer:Sixkiller6kl|sixkiller6kl]]<br />
|-<br />
| 10.50.40.88 || Knotenpunkt || Test-Server || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.98 || jabber.pm-ib.de || Jabber-Server || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.99 || K4CG || Dinge-Tester || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.100 || K4CG || Dinge-Tester || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.101 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.102 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.103 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.110 || ff_br_Spenglerstr || 5-GHz-Bridge Spenglerstr --> Johannis || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.111 || ff_Johannis || 5-GHz-Bridge Johannis --> Spenglerstr || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.120 || -- || 5-GHz-Access Point (Schniegling) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.121 || -- || 5-GHz-Client (Naturfreundehaus Nürnberg Mitte) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.122 || -- || 5-GHz-Client (Quelle GU) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.123 || -- || 5-GHz-AccessPoint (Quelle, Internetanbindung) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.130 || ff_nhgbr_Johnny || 5-GHz-Master (Standort Spenglerstr) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.131 || ff_nhgbr_NHG || 5-GHz-Slave (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.132 || ff_NHG_Osten || 5-GHz-Master (Standort Nachbarschaftshaus Goho, Richtung Osten) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.135 || ff_nhgswitch_NHG || POE-Switch (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.140 || ff_TS_PoE_tmp || 5-Port POE-Switch (für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.141 || ff_NS_M5_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.142 || ff_NS_M5_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.143 || ff_PB_5AC_500_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.144 || ff_PB_5AC_500_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.145 || ff_nhgbrsüd_M5loco_Master || 5-GHz-Master (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.146 || ff_Bauerngassebr_M5loco_Slave || 5-GHz-Slave (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.200 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Client, Routerfernwartung || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.206 || --- || lokale Dienste || [[Benutzer:meskal|meskal]]<br />
|-<br />
| 10.50.40.201 – 10.50.40.205|| Test || bitte vorläufig freihalten, danke || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.230 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.231 ||???.franken.ff || Juniper SRX (VRF) || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.232 ||???.franken.ff || Raspberry Pi || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.233 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.234 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
| 10.50.43.165 || fffsvr01.franken.freifunk.net || SMB, FTP Server 250GB || [[Benutzer:ManuelS|ManuelS]]<br />
|}<br />
<br />
=== Hood Ansbach ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.48.0 – 10.50.48.255 || || IP-Bereich Ansbach Hood || <br />
|-<br />
| 10.50.48.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.48.3 || fff-gw-cdfue1 || || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| 10.50.48.20 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.21 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.48.230 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.231 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.232 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.233 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.234 || || mom. nur Test || JuzeCr<br />
|}<br />
<br />
=== Hood Hassberge ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.56.0 – 10.50.56.255 || || IP-Bereich Hassberge Hood || <br />
|-<br />
| 10.50.56.1 || fff-has1|| || [[Server#fff-has1|Details]] <br />
|-<br />
| 10.50.56.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]] <br />
|-<br />
| 10.50.56.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.56.7 || fff-roffl|| || [[Server#fff-roffl|Details]]<br />
|-<br />
| 10.50.56.8 || fff-has3 || || [[Server#fff-has3|Details]] <br />
|-<br />
| 10.50.56.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| Bitte den Bereich 10.50.56.120 – 10.50.56.129 für [[Benutzer:Plocker|Plocker]] frei lassen<br />
|-<br />
| 10.50.56.123 || Teeworlds-Game-Server || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.124 || OwnCloud + Wiki || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.125 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.126 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.132 ||<strike> Webserver + MUD? || || [[Benutzer:PeterPhilipp|area52]]</strike><br />
|}<br />
<br />
=== Hood Hassberge Süd ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.60.0 – 10.50.60.255 || || IP-Bereich HassbergeSued Hood ||<br />
|-<br />
|<strike> 10.50.60.1</strike> || <strike>fff-has1 </strike>|| || [[Server#fff-has1|Details]]<br />
|-<br />
| 10.50.60.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.60.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.60.7 || fff-roffl|| || [[Server#fff-roffl|Details]] <br />
|-<br />
| 10.50.60.10 || Webcam Meehäusle Parkplatz|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.11 || Webcam Meehäusle Biergarten|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.100 /mediawiki || Webserver Mediawiki (in progress: Wikipedia(de)offline mirror)|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.101 /wiki || Raspi Webserver mit MediaWiki (Haßberge Wiki)|| || [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Erlangen ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.64.0 – 10.50.64.255 || || IP-Bereich Erlangen Hood || <br />
|-<br />
| 10.50.64.3 || fff-gw-yaga || || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.64.4 || fff-gw-kwadro || || [[Server#fff-gw-kwadro|Details]]<br />
|-<br />
| 10.50.64.10 || radiator.franken.ff || || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.11 || voip-1.radiator.franken.ff || Outernet, VoIP mittels SIP || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.12 || cam-1.radiator.franken.ff || IP-Cam || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.20 || radiatrix.franken.ff || geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.21 || cam-1.radiatrix.franken.ff || IP-Cam, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.22 || voip-1.radiatrix.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.30 || long.franken.ff || geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.31 || cam-1.long.franken.ff || IP-Cam || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.33 || voip-1.long.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.40 |||| Streaming Erlangen (im Aufbau) || [[Benutzer:R.funkt|R.funkt]]<br />
|-<br />
| 10.50.64.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.64.60 || gate3 || Dev || [[Benutzer:Jonas-bebe|Jonas-bebe]]<br />
|-<br />
| 10.50.64.70 |||| Raspi-Test || [[Benutzer:Dieter123|Dieter123]]<br />
|-<br />
| 10.50.64.78 |||| IP-CAM || [[Benutzer:moonrat|moonrat]]<br />
|-<br />
| 10.50.64.79 |||| IP-CAM || [[Benutzer:moonrat|moonrat]]<br />
|}<br />
<br />
=== Hood Würzburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.72.0 – 10.50.79.255 || || IP-Bereich Würzburg Hood || <br />
|-<br />
| 10.50.72.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.72.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.72.6 || fff-wue1|| || [[Server#fff-wue1|Details]] <br />
|-<br />
| 10.50.72.7 || kleeV2|| || [[Server#kleeV2|Details]] <br />
|-<br />
| 10.50.72.9 || Raspi-test|| || [[MisterCrumble|MisterCrumble]]<br />
|-<br />
| 10.50.72.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.72.72 || WikipediaClon || Soll ein Clon der Wikipedia werden. || [[Benutzer:Luensche|Luensche]]<br />
|-<br />
| 10.50.72.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood BGL ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.80.0 – 10.50.87.255 || || IP-Bereich BGL Hood || <br />
|-<br />
| 10.50.80.1 || watzmann || ||<br />
|-<br />
| 10.50.80.2 || staufen || ||<br />
|}<br />
<br />
=== Hood Nürnberger-Land ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.88.0 – 10.50.95.255 || || IP-Bereich NbgLand Hood || <br />
|-<br />
| 10.50.88.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.88.10 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.11 || fff-gw-cdnbgland2 || Gateway (Testbetrieb) || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.40 || fff-synology.freifunk-franken.de || Umzug nach Hood-Teilung || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.88.170 ||???.franken.ff || 5-GHz Richtfunk AP || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.171 ||???.franken.ff || 5-GHz Richtfunk Client || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.172 ||???.franken.ff || VM zum Testen || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood Aschaffenburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.96.0 – 10.50.103.255 || || IP-Bereich Aschaffenburg || <br />
|-<br />
| 10.50.96.x || fff-res|| || <br />
|-<br />
| 10.50.96.3 || fff-has || Gateway [[Server#fff-has|Details]]<br />
|| [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Hof ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.104.0 – 10.50.111.255 || || IP-Bereich Hof || <br />
|-<br />
| 10.50.104.1 || fff-has1 || Gateway [[Server#fff-has1|Details]]<br />
|| [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.104.2 || fff-fr1-arm || Gateway || [[User:RedDog]]<br />
|-<br />
| 10.50.104.10 || fff-gw-cdhof1 || Gateway || ChristianD<br />
|}<br />
<br />
=== Hood FabLabnbg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.132.0 – 10.50.134.255 || || IP-Bereich FabLabnbg || <br />
|-<br />
| 10.50.132.1 || fablab || Gateway FabLabnbg || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|-<br />
| 10.50.132.2 || Switch || Switch || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|-<br />
| 10.50.132.9 || Raspberry Pi || Für Alfredmaster || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.132.10 || 5GHz Test || 5GHz Test || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:RedDog|RedDog]]<br />
|}<br />
<br />
=== Hood Hardhöhe ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.130.0 – 10.50.131.255 || || IP-Bereich Hardhöhe || <br />
|-<br />
| 10.50.130.1 || fff-gw-hhd || Gateway Hardhöhedach || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.10 || fff-5g-hhd || Für eth1.3.10 am Gateway zum erreichen der 5GHz Geräte || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.11 || fff-5gs1-hhd || erste LBE-5AC-16-120 || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|-<br />
| 10.50.130.12 || fff-5gs2-hhd || zweite LBE-5AC-16-120 || [[Benutzer:ChristianD|ChristianD]] [[Benutzer:Dk5ras|Dk5ras]]<br />
|}<br />
<br />
=== Hood Aux ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
!10.50.240.1 – 10.50.247.254 || || IP-Bereich aux Hood || <br />
|-<br />
| 10.50.240.1 || fff-bbg || ||<br />
|-<br />
| 10.50.240.2 || fff-fra1 || ||<br />
|-<br />
| 10.50.240.3 || fff-gw-cdaux2 || ||<br />
|-<br />
| 10.50.240.7 || kleeV2 || ||<br />
|-<br />
| 10.50.240.20 || || Testgateway Flo für Hotel Busch |||<br />
|-<br />
| 10.50.240.11 || AP.bridge1.hoeffner.fff.community || Bridge AP Höffner || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.12 || S01.bridge1.hoeffner.fff.community || Bridge Station Hardhöhe || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.100 || fff-client-auxcd1 || Client zur Fernwartung aux || [[Benutzer:ChristianD|ChristianD]] ||<br />
|}<br />
<br />
= BSSID =<br />
<br />
{|<br />
! BSSID !! Hood !!<br />
|-<br />
| 00:ca:ff:ee:ba:be || legacy ||<br />
|-<br />
| ca:ff:ee:ba:be:00 || Trainstation ||<br />
|-<br />
| ca:ff:ee:ba:be:02 || Fürth || <br />
|-<br />
| ca:ff:ee:ba:be:03 || Nürnberg ||<br />
|-<br />
| ca:ff:ee:ba:be:04 || FabLabNbg ||<br />
|-<br />
| ca:ff:ee:ba:be:05 || Hardhöhe ||<br />
|}</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Portal:Netz&diff=6346
Portal:Netz
2016-04-28T18:28:28Z
<p>Green: /* Liste der Subnetze */</p>
<hr />
<div>== Das Netz ==<br />
Eine Karte der aktiven Router gibt es [https://monitoring.freifunk-franken.de/map].<br />
<br />
Eine Karte der Hoods ist [http://keyserver.freifunk-franken.de/fff/voronoimap.php hier] zu finden.<br />
<br />
Die [https://monitoring.freifunk-franken.de/routers Liste der Router] kann dank Monitoring immer live verfolgt werden. Infos über die Schreibweise (z.B. "/20") gibt es in der [http://de.wikipedia.org/wiki/CIDR Wikipedia].<br />
<br />
=== Gateway ===<br />
Erste Versuche einer sinnvollen Aufteilung von Gateways. Erweiterungen und Verbesserungen sind jederzeit erwünscht. [https://pad.freifunk.net/p/Gatewayaufteilung-Franken Zum Pad]<br />
<br />
== IP-Netz ==<br />
Mit der Netz-Umstellung vom 22.03.2014 haben wir nicht mehr länger ein großes [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_2_.E2.80.93_Sicherungsschicht_.28Data_Link_Layer.29 Layer-II-Netz], welches durch das [https://de.wikipedia.org/wiki/B.A.T.M.A.N. B.A.T.M.A.N. advanced]-Protokoll geroutet wird. Seitdem gibt es mehrere [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_3_.E2.80.93_Vermittlungsschicht_.28Network_Layer.29 Layer-III-Netze] (Hoods). Ein Layer-III-Netz entsteht grundsätzlich, indem hier ein Subnetz eingetragen wird. Wie dabei genau vorgegangen wird, steht in [[HoodVerwaltung]].<br />
Für jedes Subnetz muss separat abgewogen werden, wie groß es werden wird und wo es dann in die bestehenden Subnetze am besten eingegliedert werden kann.<br />
<br />
==== DHCP ====<br />
[[Datei:Hoods.png|200px|thumb|right|Vorschlag für die Hood-Organisation]]<br />
Damit simple Clients das neue Subnetz nutzen können, muss ein eigener DHCP-Server pro Subnetz bereit gestellt werden. Es macht dabei häufig Sinn, das Subnetz in IP-Bereiche aufzuteilen, die von mehreren DHCP-Servern verteilt werden. Ein zweiter DHCP-Server ermöglicht zum einen eine Lastverteilung, zum anderen erhöht sich die Ausfallsicherheit. Der DHCP-Server muss den Clients ein Default-Gateway und mindestens einen DNS-Server zuweisen. Da das Default-Gateway ebenfalls innerhalb des Subnetzes liegen muss, bietet es sich an, den selben Server, auf dem das DHCP läuft, zu nutzen.<br />
<br />
==== OLSR-Router ====<br />
Das Subnetz muss anschließend an das vorhandene Freifunknetz angeschlossen werden. Dazu muss eine Verbindung zu einem bestehenden OLSR-Router aufgebaut werden. Dies kann eine VPN-Verbindung, aber auch eine Wifi-Verbindung sein und muss individuell zwischen den zwei Parteien ausgehandelt werden. Es kann sinnvoll sein, Verbindungen zu mehr als einem OLSR-Router zu haben. Sobald der eigene Router an das OLSR-Netz angebunden ist, ist er selbst ein OLSR-Router.<br />
<br />
An den eigenen OLSR-Router können nun Accesspoints angeschlossen werden. Dies kann per VPN, WLAN, Kabel oder anderweitig geschehen. Es ist auch möglich, den Accesspoint selbst als OLSR-Router anzubinden. Auch diese Konfiguration ist individuell zu klären. Ein Accesspoint kann ein (oder mehrere) einfacher Wifi-AP oder auch ein Array von mehreren B.A.T.M.A.N.-Knoten sein. Es sollte vermieden werden, dass sich Subnetze vermischen. Dies würde immer dann passieren, wenn zwei Layer-II-Netze, die eigentlich unterschiedliche Subnetze verteilen, verbunden werden. Besonders beim B.A.T.M.A.N.-Protokoll besteht hier leicht diese Gefahr; daher sollte für jedes Subnetz eine eigene BSSID und ESSID gewählt werden.<br />
<br />
==== Aus Routersicht ====<br />
Nur Router in einer Hood können sich per B.A.T.M.A.N. advanced vermaschen, sowohl per VPN, also auch per WLAN. Daher müssen Router die räumlich nahe beieinander stehen auch in derselben Hood sein. Durch das Vermaschen des Netzes wird allerdings auch Verwaltungs-Verkehr erzeugt (Overhead). Je größer die Hood, desto größer der Overhead.<br />
<br />
Eine Verbindung zwischen Routern in unterschiedlichen Hoods ist per IP (OSI Schicht 3) möglich.<br />
<br />
Wenn im Netmon kein Standort eingegeben wurde, dann landet der Router in der Dafault-Hood.<br />
<br />
==== Monitoring (Netmon) ====<br />
Aktuell können sich Knoten nur über ein IPv6-Link-Local-Interface beim Netmon anmelden und Netmon kann die Knoten nur über eine IPv6-Link-Local-Adresse abfragen. Hier muss ein neuer Mechanismus gefunden werden, der es ermöglicht, die Knoten über Subnetze hinweg anzusprechen.<br />
<br />
Als Workaround ist es möglich, über einen Layer-II-Tunnel zum Netmon-Server das Subnetz an das Netmon anzubinden. Auf dem Netmon-Server werden alle Subnetze in einem Bridge-Interface zusammengefasst, welches keine Pakete weiterleiten kann.<br />
<br />
==== Wireless-LAN ====<br />
Wir haben uns auf folgende WLAN-Parameter verständigt:<br />
'''ESSID: franken.freifunk.net'''. Kanal 1.<br />
<br />
== Liste der Subnetze ==<br />
{|<br />
! !! Bereich !! Bereitgestellt durch<br />
|-<br />
! 10.50.0.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.0.1 – 10.50.15.254</font> || <br />
|-<br />
! 10.50.16.0/20 || Default Hood ||<br />
|-<br />
| || 10.50.16.1 – 10.50.17.255 || Statische Adressen<br />
|-<br />
| || 10.50.18.0 – 10.50.19.255 || --<br />
|-<br />
| || 10.50.20.0 – 10.50.21.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey">10.50.22.0 – 10.50.23.254 </font> || <br />
|-<br />
| || <font color="grey">10.50.24.0 – 10.50.31.254 </font> || <br />
|-<br />
! 10.50.32.0/21 || Fürth Hood ||<br />
|-<br />
| || 10.50.32.1 – 10.50.32.255 || Statische Adressen<br />
|-<br />
| || 10.50.33.0 – 10.50.34.255 || [[fff-nue2|fff-nue2-gw1]]<br />
|-<br />
| || 10.50.35.0 – 10.50.36.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey"> 10.50.37.0 – 10.50.37.255 </font> || --<br />
|-<br />
| || 10.50.38.0 – 10.50.39.254 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.40.0/21 || Nürnberg Hood ||<br />
|-<br />
| || 10.50.40.1 – 10.50.40.255 || Statische Adressen<br />
|-<br />
| || 10.50.41.0 – 10.50.42.255 || [[Server#FFF-GW-M1|FFF-GW-M1]]<br />
|-<br />
| || <font color="grey"> 10.50.43.0 - 10.50.43.255 </font> || <br />
|-<br />
| || 10.50.44.0 – 10.50.44.255 || (umgezogen) [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| ||10.50.45.0 – 10.50.46.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.47.0 – 10.50.47.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.48.0/21 || Ansbach Hood ||<br />
|-<br />
| || 10.50.48.1 – 10.50.48.255 || Statische Adressen<br />
|-<br />
| || 10.50.49.0 – 10.50.50.255 || <br />
|-<br />
| || 10.50.51.0 – 10.50.52.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.53.0 – 10.50.54.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| || <font color="grey">10.50.55.0 – 10.50.55.254</font> || <br />
|-<br />
! 10.50.56.0/22 || Hassberge Hood ||<br />
|-<br />
| || 10.50.56.1 – 10.50.56.255 || Statische Adressen<br />
|-<br />
| || 10.50.57.0 – 10.50.57.255 || [[Server#fff-has3|fff-has3]]<br />
|-<br />
| || 10.50.58.0 – 10.50.58.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.59.0 – 10.50.59.254 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
! 10.50.60.0/22 || HassbergeSued Hood ||<br />
|-<br />
| || 10.50.60.1 – 10.50.60.255 || Statische Adressen<br />
|-<br />
| || 10.50.61.0 – 10.50.61.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
| || 10.50.62.0 – 10.50.62.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.63.0 – 10.50.63.254 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
! 10.50.64.0/21 || Erlangen Hood ||<br />
|-<br />
| || 10.50.64.1 – 10.50.64.255 || Statische Adressen<br />
|-<br />
| || 10.50.65.0 – 10.50.66.255 || [[Server#fff-gw-kwadro|fff-gw-kwadro]]<br />
|-<br />
| || 10.50.67.0 – 10.50.68.255 || free<br />
|-<br />
| || 10.50.69.0 – 10.50.71.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.72.0/21 || Würzburg Hood ||<br />
|-<br />
| || 10.50.72.1 – 10.50.72.255 || Statische Adressen<br />
|-<br />
| || <font color="grey"> 10.50.73.0 – 10.50.74.255 </font>|| <br />
|-<br />
| || 10.50.75.0 – 10.50.76.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.77.0 – 10.50.78.255 || [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || 10.50.79.0 – 10.50.79.254 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
! 10.50.80.0/21 || BGL ||<br />
|-<br />
| || 10.50.80.1 – 10.50.80.255 || Statische Adressen<br />
|-<br />
| || 10.50.81.0 – 10.50.82.255 || [[Server#watzmann|watzmann]]<br />
|-<br />
| || 10.50.83.0 – 10.50.84.255 || [[Server#staufen|staufen]]<br />
|-<br />
! 10.50.88.0/21 || NbgLand Hood ||<br />
|-<br />
| || 10.50.88.1 – 10.50.88.255 || Statische Adressen<br />
|-<br />
| || 10.50.89.0 – 10.50.89.255 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| || 10.50.90.0 - 10.50.91.255 || fff-gw-cdnbgland2 (Testbetrieb)<br />
|-<br />
| || <font color="grey">10.50.92.0 - 10.50.93.255</font> || <br />
|-<br />
| || 10.50.94.0 – 10.50.95.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.96.0/21 || Aschaffenburg Hood ||<br />
|-<br />
| || 10.50.96.1 – 10.50.96.255 || Statische Adressen<br />
|-<br />
| || 10.50.97.1 – 10.50.97.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
! 10.50.104.0/21 || Hof Hood ||<br />
|-<br />
| || 10.50.104.1 – 10.50.104.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.105.0 - 10.50.106.255</font> || free<br />
|-<br />
| || 10.50.107.0 – 10.50.107.255 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
| || 10.50.108.0 - 10.50.109.255 || fff-fr1-x86<br />
|-<br />
| || 10.50.110.1 - 10.50.111.254 || fff-gw-cdhof1<br />
|-<br />
! 10.50.112.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.112.1 – 10.50.119.254</font> || <br />
|-<br />
! 10.50.120.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.120.1 – 10.50.127.254</font> || <br />
|-<br />
! 10.50.128.0/24 || Test von Casandro ||<br />
|-<br />
| || 10.50.128.20 – 10.50.128.200 || 10.50.128.1<br />
|-<br />
! 10.50.129.0/24 || free ||<br />
|-<br />
| || 10.50.129.0 || free<br />
|-<br />
! 10.50.130.0/23 || Hardhöhe ||<br />
|-<br />
| || 10.50.130.1 - 10.50.130.255 || Statische Adressen<br />
|-<br />
| || 10.50.131.0 – 10.50.131.127 || Gateway Hochhaus<br />
|-<br />
! 10.50.132.0/22 || FabLabNbg Hood ||<br />
|-<br />
| || 10.50.132.1 - 10.50.132.255 || Statische Adressen<br />
|-<br />
| || 10.50.133.0 – 10.50.133.255 || FabLabNbgGW<br />
|-<br />
| || 10.50.134.0 - 10.50.135.254 || frei<br />
|-<br />
! 10.50.136.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.136.1 – 10.50.143.254</font> || <br />
|-<br />
! 10.50.144.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.144.1 – 10.50.159.254</font> || <br />
|-<br />
! 10.50.160.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.160.1 – 10.50.191.254</font> || <br />
|-<br />
! 10.50.192.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.192.1 – 10.50.223.254</font> || <br />
|-<br />
! 10.50.224.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.224.1 – 10.50.239.254</font> || <br />
|-<br />
! 10.50.240.0/21 || fffaux ||<br />
|-<br />
| || 10.50.240.1 – 10.50.240.255 || Statische Adressen<br />
|-<br />
| || 10.50.241.0 – 10.50.241.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.242.0 – 10.50.243.255 || [[Server#fff-fra1|fff-fra1]]<br />
|-<br />
| || 10.50.244.0 – 10.50.244.127 || Testinstallation Busch (Flo)<br />
|-<br />
| || 10.50.244.128 - 10.50.245.255 || | [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || <font color="grey">10.50.246.0 - 10.50.247.254</font> || <br />
|-<br />
<br />
! 10.50.248.0/22 || free ||<br />
|-<br />
| || 10.50.248.1 – 10.50.248.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.249.0 - 10.50.251.254</font> || <br />
|-<br />
! 10.50.252.0/22 || TUNNEL ||<br />
|-<br />
| || 10.50.252.0 fff_ro1 || 10.50.252.1 nue1 || <br />
|-<br />
| || 10.50.252.2 fff_ro1 || 10.50.252.3 watzmann || <br />
|-<br />
| || 10.50.252.4 fff_ro1 || 10.50.252.5 staufen || <br />
|-<br />
| || 10.50.252.6 fff_ro1 || 10.50.252.7 has2 || <br />
|-<br />
| || 10.50.252.8 fff_ro1 || 10.50.252.9 has || <br />
|-<br />
| || 10.50.252.10 ro1 || 10.50.252.11 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.12 fff-has2 || 10.50.252.13 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.14 fff-gw-m1 || 10.50.252.15 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.16 KleeV2 || 10.50.252.17 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.18 KleeV2 || 10.50.252.19 nue1 ||<br />
|-<br />
| || 10.50.252.20 KleeV2 || 10.50.252.21 ro1 ||<br />
|-<br />
| || 10.50.252.22 fff-gw-yaga || 10.50.252.23 fff-wue1 ||<br />
|-<br />
| || 10.50.252.24 fff-gw-m1 || 10.50.252.25 fff-has2 ||<br />
|-<br />
| || 10.50.252.26 fff-gw-m1 || 10.50.252.27 fff-wue1 ||<br />
|-<br />
| || 10.50.252.28 fff-bbg || 10.50.252.29 fff-nue1 ||<br />
|-<br />
| || 10.50.252.30 fff-bbg || 10.50.252.31 fff-ro1 ||<br />
|-<br />
| || 10.50.252.32 fff-bbg || 10.50.252.33 fff-has2 ||<br />
|-<br />
| || 10.50.252.34 fff-bbg || 10.50.252.35 KleeV2 ||<br />
|-<br />
| || 10.50.252.36 fff-wue1 || 10.50.252.37 fff-bbg ||<br />
|-<br />
| || 10.50.252.38 fff-gw-m1 || 10.50.252.39 ro1 ||<br />
|-<br />
| || 10.50.252.40 fff-gw-yaga || 10.50.252.41 ro1 ||<br />
|-<br />
| || 10.50.252.42 fff-gw-yaga || 10.50.252.43 nue1 ||<br />
|-<br />
| || 10.50.252.44 fff-roffl || 10.50.252.45 fff-has2 ||<br />
|-<br />
| || 10.50.252.46 fff-fra1 || 10.50.252.47 fff-bbg ||<br />
|-<br />
| || 10.50.252.48 fff-fra1 || 10.50.252.49 kleeV2 ||<br />
|-<br />
| || 10.50.252.50 fff-roffl || 10.50.252.51 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.52 fff-has2 || 10.50.252.53 kleeV2 ||<br />
|-<br />
| || 10.50.252.54 fff-has2 || 10.50.252.55 fff-fra1 ||<br />
|-<br />
| || 10.50.252.56 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.57 kwadronaut ||<br />
|-<br />
| || 10.50.252.58 fff-gw-m1 || 10.50.252.59 kwadronaut ||<br />
|-<br />
| || 10.50.252.60 fff-nue1 || 10.50.252.61 kwadronaut ||<br />
|-<br />
| || 10.50.252.62 ro1 || 10.50.252.63 kwadronaut ||<br />
|-<br />
| || 10.50.252.64 staufen || 10.50.252.65 kwadronaut ||<br />
|-<br />
| || 10.50.252.66 watzmann || 10.50.252.67 kwadronaut ||<br />
|-<br />
| || 10.50.252.68 kwadronaut || 10.50.252.69 yaga ||<br />
|-<br />
| || 10.50.252.70 fff-has || 10.50.252.71 nue1 ||<br />
|-<br />
| || 10.50.252.72 fff-has || 10.50.252.73 fff-wue1 ||<br />
|-<br />
| || 10.50.252.74 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.75 fff-dns-cd1 ||<br />
|-<br />
| || 10.50.252.76 fff-has || 10.50.252.77 fff-has1 ||<br />
|-<br />
| || 10.50.252.78 fff-roffl || 10.50.252.79 fff-has1 ||<br />
|-<br />
| || 10.50.252.80 fff-has2 || 10.50.252.81 fff-has1 ||<br />
|-<br />
| || 10.50.252.82 fff-has || 10.50.252.83 fff-has3 ||<br />
|-<br />
| || 10.50.252.84 fff-has2 || 10.50.252.85 fff-has3 ||<br />
|-<br />
| || 10.50.252.86 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.87 fff-dns-cd2 ||<br />
|-<br />
| || 10.50.252.88 ro1 || 10.50.252.89 fablabnbggw ||<br />
|-<br />
| || 10.50.252.90 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.91 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.92 fff-has || 10.50.252.93 fff-has2 ||<br />
|-<br />
| || 10.50.252.94 ro1 || 10.50.252.95 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.96 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.97 fff-gw-cd2 ||<br />
|-<br />
| || 10.50.252.98 fff-gw-cd2 || 10.50.252.99 fff-nue2-gw1 ||<br />
|-<br />
| || 10.50.252.100 fff-gw-cd2 || 10.50.252.101 has2 ||<br />
|-<br />
| || 10.50.252.102 fff-gw-cd2 || 10.50.252.103 fff-gw-m1 ||<br />
|-<br />
| || 10.50.252.250 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.251 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.252 Testsystem von [[Benutzer:ChristianD]] || 10.50.252.253 Testsystem2 von [[Benutzer:ChristianD]] ||<br />
|-<br />
! 10.83.0.0/16 || free for tests ||<br />
|-<br />
| || <font color="grey">10.83.0.1 - 10.83.255.254</font> || <br />
|-<br />
|}<br />
<br />
== Statische IP-Adressen ==<br />
Dienste müssen Ihre IP-Adressen natürlich aus dem Subnetz beziehen, in welchem sie angeschlossen sind. Damit es keine Konflikte gibt, muss die IP-Adresse hier registriert werden.<br />
<br />
=== Default Hood ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.16.0 – 10.50.17.255 || || IP-Bereich Default Hood || <br />
|-<br />
| 10.50.16.2 || fff-nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.16.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.16.11 || c.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.21 || rns3.franken.ff || DNS PoC - Recursor #3 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.16.100 || netmon.freifunk-franken.de || || [[Server#si1|Details]]<br />
|-<br />
| 10.50.16.112 ||???.franken.ff || Raspberry Pi, Test owncloud, FTP || MartinS<br />
|-<br />
| 10.50.16.128 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.150 ||Diagnose ChristianD || Diagnose ChristianD || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.16.200 ||???.franken.ff || Fileserver || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.16.212 ||???.franken.ff || NAS, verschiedene Services || JomJom<br />
|-<br />
| 10.50.16.222 ||???.franken.ff || VM, mom. nur Test || pixelchrome<br />
|-<br />
| 10.50.17.112 ||???.franken.ff || Webserver, Tests || wolli112<br />
|}<br />
<br />
=== Hood Fürth ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.32.0 – 10.50.32.255 || || IP-Bereich Fürth Hood || <br />
|-<br />
| 10.50.32.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.32.3 || fff-uk1.freifunk-franken.de || || [[Server#fff-uk1|Details]]<br />
|-<br />
| 10.50.32.4 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|- <br />
| 10.50.32.5 || [[fff-nue2|fff-nue2-gw1]] || Gateway || [[Benutzer:RedDog|RedDog]] [[Benutzer:Mayosemmel|Mayosemmel]] [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.6 || frei || ||<br />
|- <br />
| <font color="grey"> 10.50.32.7 </font>||<font color="grey"> (frei) </font> || ||<br />
|-<br />
| 10.50.32.26 || Test-PI || Statische IP des RasPI für Testzwecke || [[Benutzer:Hobo|Hobo]] <br />
|-<br />
| 10.50.32.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.32.70 || testbridgeap.bridge.fff.community || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.71 || testbridgeclient.bridge.fff.community || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.100 || MicroNAS || anonymous FTP (10GB) || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.101 || Wetterstation || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Daten bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.102 || Wetterkamera || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Bilder bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.109 || Raspi || Raspi Server im Höffner || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.110 || - || - || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.111 || stmichael.bridge.ws13.fff.community || Nanobeam M5 Bridge als AP auf St. Michael Richtung DelphiN || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.112 || ws13.bridge.stmichael.fff.community || Nanobeam M5 Bridge als Client bei DelphiN. Richtung St. Michael || [[Benutzer:delphiN|delphiN]], [[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.113 || || Bridge als AP auf St. Michael. Richtung Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.114 || || Bridge als Client bei Hoeffner. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.117 || || ToughSwitch Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.118 || || ToughSwitch auf WS13 || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.119 || || ToughSwitch auf StMichael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.120 || || ToughSwitch im Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.121 || || Bridge als AP auf St. Michael. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.122 || || Bridge als Client in Europaallee. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.123 || || Reserviert: Bridge als AP auf Hardhöhe. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.124 || || Bridge als Client in Europaallee. Richtung Hardhöhe || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.150 || ChristianD's PC || FFF-Netz ohne Internet || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.151 || feste Laptop IP || Für Speedtests mit manuellen Gateway || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.152 || RasPi || Testsystem || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.170 || HoeffnerPrinter || Drucker Computerraum Höffner || [[Benutzer:delphiN|delphiN]] <br />
|-<br />
| 10.50.32.199 || || Ralphs home-server ftp/http || [[Benutzer:dk5ras|dk5ras]] <br />
|}<br />
<br />
=== Hood Nürnberg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.40.0 – 10.50.40.255 || || IP-Bereich Nürnberg Hood || <br />
|-<br />
|<strike>10.50.40.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.40.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.40.7 || fff-gw-yaga|| || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.40.8 || fff-bbg|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.10 || FFF-GW-M1 || || [[Server#FFF-GW-M1|Details]]<br />
|-<br />
| 10.50.40.11 || a.ns.franken.ff || DNS PoC - Master || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.12 || b.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.20 || - – - || Direct Connect HUB || [[Benutzer:TheFroggy|TheFroggy]]<br />
|-<br />
| 10.50.40.21 || rns1.franken.ff || DNS PoC - Recursor #1 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.22 || rns2.franken.ff || DNS PoC - Recursor #2 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| <strike>10.50.40.40</strike> || <strike>fff-synology.freifunk-franken.de</strike> || Umgezogen nach NBGLand || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.40.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.40.51 || mayo-test.fff.community || || [[Benutzer:mayosemmel|mayosemmel]]<br />
|-<br />
| 10.50.40.52 || VPN ins FF || || [[Benutzer:mayosemmel|mayosemmel]]<br />
|-<br />
| 10.50.40.66 || flightradar.freifunk-franken.de || Dump1090 || [[Benutzer:Sixkiller6kl|sixkiller6kl]]<br />
|-<br />
| 10.50.40.88 || Knotenpunkt || Test-Server || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.98 || jabber.pm-ib.de || Jabber-Server || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.101 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.102 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.103 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.110 || ff_br_Spenglerstr || 5-GHz-Bridge Spenglerstr --> Johannis || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.111 || ff_Johannis || 5-GHz-Bridge Johannis --> Spenglerstr || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.120 || -- || 5-GHz-Access Point (Schniegling) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.121 || -- || 5-GHz-Client (Naturfreundehaus Nürnberg Mitte) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.122 || -- || 5-GHz-Client (Quelle GU) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.123 || -- || 5-GHz-AccessPoint (Quelle, Internetanbindung) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.130 || ff_nhgbr_Johnny || 5-GHz-Master (Standort Spenglerstr) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.131 || ff_nhgbr_NHG || 5-GHz-Slave (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.132 || ff_NHG_Osten || 5-GHz-Master (Standort Nachbarschaftshaus Goho, Richtung Osten) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.135 || ff_nhgswitch_NHG || POE-Switch (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.140 || ff_TS_PoE_tmp || 5-Port POE-Switch (für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.141 || ff_NS_M5_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.142 || ff_NS_M5_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.143 || ff_PB_5AC_500_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.144 || ff_PB_5AC_500_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.145 || ff_nhgbrsüd_M5loco_Master || 5-GHz-Master (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.146 || ff_Bauerngassebr_M5loco_Slave || 5-GHz-Slave (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.200 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Client, Routerfernwartung || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.201 – 10.50.40.205|| Test || bitte vorläufig freihalten, danke || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.230 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.231 ||???.franken.ff || Juniper SRX (VRF) || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.232 ||???.franken.ff || Raspberry Pi || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.233 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.234 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
| 10.50.43.165 || fffsvr01.franken.freifunk.net || SMB, FTP Server 250GB || [[Benutzer:ManuelS|ManuelS]]<br />
|}<br />
<br />
=== Hood Ansbach ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.48.0 – 10.50.48.255 || || IP-Bereich Ansbach Hood || <br />
|-<br />
| 10.50.48.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.48.3 || fff-gw-cdfue1 || || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| 10.50.48.20 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.21 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.48.230 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.231 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.232 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.233 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.234 || || mom. nur Test || JuzeCr<br />
|}<br />
<br />
=== Hood Hassberge ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.56.0 – 10.50.56.255 || || IP-Bereich Hassberge Hood || <br />
|-<br />
| 10.50.56.1 || fff-has1|| || [[Server#fff-has1|Details]] <br />
|-<br />
| 10.50.56.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]] <br />
|-<br />
| 10.50.56.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.56.7 || fff-roffl|| || [[Server#fff-roffl|Details]]<br />
|-<br />
| 10.50.56.8 || fff-has3 || || [[Server#fff-has3|Details]] <br />
|-<br />
| 10.50.56.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| Bitte den Bereich 10.50.56.120 – 10.50.56.129 für [[Benutzer:Plocker|Plocker]] frei lassen<br />
|-<br />
| 10.50.56.123 || Teeworlds-Game-Server || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.124 || OwnCloud + Wiki || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.125 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.126 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.132 ||<strike> Webserver + MUD? || || [[Benutzer:PeterPhilipp|area52]]</strike><br />
|}<br />
<br />
=== Hood Hassberge Süd ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.60.0 – 10.50.60.255 || || IP-Bereich HassbergeSued Hood ||<br />
|-<br />
|<strike> 10.50.60.1</strike> || <strike>fff-has1 </strike>|| || [[Server#fff-has1|Details]]<br />
|-<br />
| 10.50.60.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.60.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.60.7 || fff-roffl|| || [[Server#fff-roffl|Details]] <br />
|-<br />
| 10.50.60.10 || Webcam Meehäusle Parkplatz|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.11 || Webcam Meehäusle Biergarten|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.100 /mediawiki || Webserver Mediawiki (in progress: Wikipedia(de)offline mirror)|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.101 /wiki || Raspi Webserver mit MediaWiki (Haßberge Wiki)|| || [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Erlangen ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.64.0 – 10.50.64.255 || || IP-Bereich Erlangen Hood || <br />
|-<br />
| 10.50.64.3 || fff-gw-yaga || || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.64.4 || fff-gw-kwadro || || [[Server#fff-gw-kwadro|Details]]<br />
|-<br />
| 10.50.64.10 || radiator.franken.ff || || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.11 || voip-1.radiator.franken.ff || Outernet, VoIP mittels SIP || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.12 || cam-1.radiator.franken.ff || IP-Cam || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.20 || radiatrix.franken.ff || geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.21 || cam-1.radiatrix.franken.ff || IP-Cam, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.22 || voip-1.radiatrix.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.30 || long.franken.ff || geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.31 || cam-1.long.franken.ff || IP-Cam || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.33 || voip-1.long.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.40 |||| Streaming Erlangen (im Aufbau) || [[Benutzer:R.funkt|R.funkt]]<br />
|-<br />
| 10.50.64.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.64.60 || gate3 || Dev || [[Benutzer:Jonas-bebe|Jonas-bebe]]<br />
|-<br />
| 10.50.64.70 |||| Raspi-Test || [[Benutzer:Dieter123|Dieter123]]<br />
|-<br />
| 10.50.64.78 |||| IP-CAM || [[Benutzer:moonrat|moonrat]]<br />
|-<br />
| 10.50.64.79 |||| IP-CAM || [[Benutzer:moonrat|moonrat]]<br />
|}<br />
<br />
=== Hood Würzburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.72.0 – 10.50.79.255 || || IP-Bereich Würzburg Hood || <br />
|-<br />
| 10.50.72.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.72.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.72.6 || fff-wue1|| || [[Server#fff-wue1|Details]] <br />
|-<br />
| 10.50.72.7 || kleeV2|| || [[Server#kleeV2|Details]] <br />
|-<br />
| 10.50.72.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.72.72 || WikipediaClon || Soll ein Clon der Wikipedia werden. || [[Benutzer:Luensche|Luensche]]<br />
|-<br />
| 10.50.72.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood BGL ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.80.0 – 10.50.87.255 || || IP-Bereich BGL Hood || <br />
|-<br />
| 10.50.80.1 || watzmann || ||<br />
|-<br />
| 10.50.80.2 || staufen || ||<br />
|}<br />
<br />
=== Hood Nürnberger-Land ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.88.0 – 10.50.95.255 || || IP-Bereich NbgLand Hood || <br />
|-<br />
| 10.50.88.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.88.10 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.11 || fff-gw-cdnbgland2 || Gateway (Testbetrieb) || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.40 || fff-synology.freifunk-franken.de || Umzug nach Hood-Teilung || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.88.170 ||???.franken.ff || 5-GHz Richtfunk AP || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.171 ||???.franken.ff || 5-GHz Richtfunk Client || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.172 ||???.franken.ff || VM zum Testen || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood Aschaffenburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.96.0 – 10.50.103.255 || || IP-Bereich Aschaffenburg || <br />
|-<br />
| 10.50.96.x || fff-res|| || <br />
|-<br />
| 10.50.96.3 || fff-has || Gateway [[Server#fff-has|Details]]<br />
|| [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Hof ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.104.0 – 10.50.111.255 || || IP-Bereich Hof || <br />
|-<br />
| 10.50.104.1 || fff-has1 || Gateway [[Server#fff-has1|Details]]<br />
|| [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.104.2 || fff-fr1-x86 || Gateway || [[User:RedDog]]<br />
|-<br />
| 10.50.104.10 || fff-gw-cdhof1 || Gateway || ChristianD<br />
|}<br />
<br />
=== Hood Aux ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
!10.50.240.1 – 10.50.247.254 || || IP-Bereich aux Hood || <br />
|-<br />
| 10.50.240.1 || fff-bbg || ||<br />
|-<br />
| 10.50.240.2 || fff-fra1 || ||<br />
|-<br />
| 10.50.240.7 || kleeV2 || ||<br />
|-<br />
| 10.50.240.20 || || Testgateway Flo für Hotel Busch |||<br />
|-<br />
| 10.50.240.11 || AP.bridge1.hoeffner.fff.community || Bridge AP Höffner || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.12 || S01.bridge1.hoeffner.fff.community || Bridge Station Hardhöhe || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.100 || fff-client-auxcd1 || Client zur Fernwartung aux || [[Benutzer:ChristianD|ChristianD]] ||<br />
|}<br />
<br />
= BSSID =<br />
<br />
{|<br />
! BSSID !! Hood !!<br />
|-<br />
| 00:ca:ff:ee:ba:be || legacy ||<br />
|-<br />
| ca:ff:ee:ba:be:00 || Trainstation ||<br />
|-<br />
| ca:ff:ee:ba:be:02 || Fürth || <br />
|-<br />
| ca:ff:ee:ba:be:03 || Nürnberg ||<br />
|-<br />
| ca:ff:ee:ba:be:04 || FabLabNbg ||<br />
|-<br />
| ca:ff:ee:ba:be:05 || Hardhöhe ||<br />
|}</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Liste_bekannter_Aux-FW_Router&diff=5839
Liste bekannter Aux-FW Router
2016-03-05T22:01:11Z
<p>Green: </p>
<hr />
<div>Um den Überblick über die mit Aux-FW geflashten Router zu behalten, wird eine Übersichtstabelle über die bekannten (d.h. zurückgemeldeten) Router geführt.<br />
<br />
{|<br />
! Routername !! Router-MAC !! gemeldet von !! gemeldet am !! Bemerkungen<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1317 Notunterkunft Turnhalle] || 14CC204D4786 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1318 Notunterkunft Turnhalle1] || 30B5C2AC26D8 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1355 ArnsteinerNetz0001] || 30:b5:c2:bd:77:ba || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1716 ArnsteinerNetz0002] || 30.b5:c2:bd:78:86 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1484 ArnsteinerNetz0005] || 30:b5:c2:88:47:14 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1754 ArnsteinerNetz0006] || 30:b5:c2:88:4e:00 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1248 ArnsteinerNetz002] || 30:b5:c2:d9:c8:ae || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1247 ArnsteinerNetz003] || 30:b5:c2:d9:c8:18 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1753 ArnsteinerNetz004] || 30:b5:c2:d9:c6:de || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || reiner AP, kein Mesh, Clientzählung durch Meshrouter "ArnsteinerNetz002" 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=583 WS13W01WR1043] || e8:de:27:fd:2b:aa || [https://netmon.freifunk-franken.de/user.php?user_id=6 delphiN] || 03.11.2015 || Beta 2 Testbetrieb<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1768 HabuRef01] || 30B5C20E8AE0 || [https://netmon.freifunk-franken.de/user.php?user_id=438 DerMichy] || 15.11.2015 || Pending installation in Hammelburg, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1766 Tannenberg01] || 60:E3:27:2A:56:46 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1769 Tannenberg02] || 30:B5:C2:E2:FD:EE || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1770 Tannenberg03] || 60:E3:27:2A:58:E4 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2066 Tannenberg04] || 60:E3:27:59:E3:C8 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 05.01.2016 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1751 AHKRockenbrunner1] || A0:F3:C1:76:4F:20 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=860 AHKRockenbrunner2] || C0:4A:00:0B:A8:94 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=856 AHKRockenbrunner3] || C4:6E:1F:F5:F4:AC || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1861 AHKRockenbrunner4] || 30:B5:C2:81:08:DA || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1650 OBT1] || 14cc2030e9ce || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1651 OBT2] || 14CC2030EA0C || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1659 OBT3] || 30B5C2D9B4AE || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1781 OBT4] || 30B5C2D9BD72 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1782 OBT5] || 30B5C2D9B522 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1842 ap1.refugees.kleinheubach] || 30:B5:C2:B0:56:0E || [https://netmon.freifunk-franken.de/user.php?user_id=446 oswald] || 30.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1847 stein-knauppstr-01] || C46E1F3B4262 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1845 stein-knauppstr-02] || E894F66D16A2 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1844 stein-knauppstr-03] || E894F6B981F6 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1848 stein-knauppstr-04] || 10FEEDCD9B3C || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1904 AsylcenterEbelsbach] || 30B5C2E301A6 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1319 AsylcenterEbelsbach1] || 30B5C2CB356C || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1591 refugees21.wue] || 68:72:51:2c:2f:9c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1602 refugees22.wue] || 12:bc:f9:69:d3:5c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1610 refugees23.wue] || 68:72:51:2c:30:bb || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2005 wue.N2N-ev.refugees.aux.001] || 60:e3:27:bd:ce:08 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2004 wue.N2N-ev.refugees.aux.002] || 60:e3:27:c7:30:3c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1819 wue.N2N-ev.refugees.aux.003] || 60:e3:27:c7:2f:d6 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2014 wue.N2N-ev.refugees.aux.004] || 14:cc:20:87:3c:5e || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2010 wue.N2N-ev.refugees.aux.005] || 60:e3:27:82:00:72 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2011 wue.N2N-ev.refugees.aux.006] || 60:e3:27:82:0a:3a || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2012 wue.N2N-ev.refugees.aux.007] || 68:72:51:2c:2c:28 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=2143 NotunterkunftGerbrunn0] || 30:B5:C2:3E:84:A2 || [https://netmon.freifunk-franken.de/user.php?user_id=630 dasaweb] || 17.01.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=1260 aux.refugees3.wue] || 30B5C222F3C4 || [https://netmon.freifunk-franken.de/user.php?user_id=433 malleze_wue] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=1261 aux.refugees4.wue] || 30B5C222D3B8 || [https://netmon.freifunk-franken.de/user.php?user_id=433 malleze_wue] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=1339 aux.refugees7.wue] || 647002F71C1E || [https://netmon.freifunk-franken.de/user.php?user_id=433 malleze_wue] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=1865 aux.refugees27.wue] || 14CC20E3E9A2 || [https://netmon.freifunk-franken.de/user.php?user_id=433 malleze_wue] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=2434 aux.refugees40.wue] || 30B5C222D3B8 || [https://netmon.freifunk-franken.de/user.php?user_id=433 malleze_wue] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=1368 refugees14.wue] || C46E1F2B9B90 || [https://netmon.freifunk-franken.de/user.php?user_id=459 DiLeGreen] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=2317 ap2.refugees.kleinheubach] || 14:cc:20:cd:4e:46 || [https://netmon.freifunk-franken.de/user.php?user_id=446 oswald] || 16.02.2016 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1586 OBT6] || c4:6e:1f:a2:53:4a || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 05.03.2016 ||<br />
|}<br />
<br />
Mehr Infos über die Aux-Firmware [https://wiki.freifunk-franken.de/w/Was_ist_die_aux_Firmware hier.]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Liste_bekannter_Aux-FW_Router&diff=5827
Liste bekannter Aux-FW Router
2016-03-02T18:05:17Z
<p>Green: </p>
<hr />
<div>Um den Überblick über die mit Aux-FW geflashten Router zu behalten, wird eine Übersichtstabelle über die bekannten (d.h. zurückgemeldeten) Router geführt.<br />
<br />
{|<br />
! Routername !! Router-MAC !! gemeldet von !! gemeldet am !! Bemerkungen<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1317 Notunterkunft Turnhalle] || 14CC204D4786 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1318 Notunterkunft Turnhalle1] || 30B5C2AC26D8 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1355 ArnsteinerNetz0001] || 30:b5:c2:bd:77:ba || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1716 ArnsteinerNetz0002] || 30.b5:c2:bd:78:86 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1484 ArnsteinerNetz0005] || 30:b5:c2:88:47:14 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1754 ArnsteinerNetz0006] || 30:b5:c2:88:4e:00 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1248 ArnsteinerNetz002] || 30:b5:c2:d9:c8:ae || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1247 ArnsteinerNetz003] || 30:b5:c2:d9:c8:18 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1753 ArnsteinerNetz004] || 30:b5:c2:d9:c6:de || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || reiner AP, kein Mesh, Clientzählung durch Meshrouter "ArnsteinerNetz002" 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=583 WS13W01WR1043] || e8:de:27:fd:2b:aa || [https://netmon.freifunk-franken.de/user.php?user_id=6 delphiN] || 03.11.2015 || Beta 2 Testbetrieb<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1768 HabuRef01] || 30B5C20E8AE0 || [https://netmon.freifunk-franken.de/user.php?user_id=438 DerMichy] || 15.11.2015 || Pending installation in Hammelburg, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1766 Tannenberg01] || 60:E3:27:2A:56:46 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1769 Tannenberg02] || 30:B5:C2:E2:FD:EE || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1770 Tannenberg03] || 60:E3:27:2A:58:E4 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2066 Tannenberg04] || 60:E3:27:59:E3:C8 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 05.01.2016 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1751 AHKRockenbrunner1] || A0:F3:C1:76:4F:20 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=860 AHKRockenbrunner2] || C0:4A:00:0B:A8:94 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=856 AHKRockenbrunner3] || C4:6E:1F:F5:F4:AC || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1861 AHKRockenbrunner4] || 30:B5:C2:81:08:DA || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1650 OBT1] || 14cc2030e9ce || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1651 OBT2] || 14CC2030EA0C || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1659 OBT3] || 30B5C2D9B4AE || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1781 OBT4] || 30B5C2D9BD72 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1782 OBT5] || 30B5C2D9B522 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1842 ap1.refugees.kleinheubach] || 30:B5:C2:B0:56:0E || [https://netmon.freifunk-franken.de/user.php?user_id=446 oswald] || 30.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1847 stein-knauppstr-01] || C46E1F3B4262 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1845 stein-knauppstr-02] || E894F66D16A2 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1844 stein-knauppstr-03] || E894F6B981F6 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1848 stein-knauppstr-04] || 10FEEDCD9B3C || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1904 AsylcenterEbelsbach] || 30B5C2E301A6 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1319 AsylcenterEbelsbach1] || 30B5C2CB356C || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1591 refugees21.wue] || 68:72:51:2c:2f:9c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1602 refugees22.wue] || 12:bc:f9:69:d3:5c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1610 refugees23.wue] || 68:72:51:2c:30:bb || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2005 wue.N2N-ev.refugees.aux.001] || 60:e3:27:bd:ce:08 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2004 wue.N2N-ev.refugees.aux.002] || 60:e3:27:c7:30:3c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1819 wue.N2N-ev.refugees.aux.003] || 60:e3:27:c7:2f:d6 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2014 wue.N2N-ev.refugees.aux.004] || 14:cc:20:87:3c:5e || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2010 wue.N2N-ev.refugees.aux.005] || 60:e3:27:82:00:72 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2011 wue.N2N-ev.refugees.aux.006] || 60:e3:27:82:0a:3a || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2012 wue.N2N-ev.refugees.aux.007] || 68:72:51:2c:2c:28 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=2143 NotunterkunftGerbrunn0] || 30:B5:C2:3E:84:A2 || [https://netmon.freifunk-franken.de/user.php?user_id=630 dasaweb] || 17.01.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=1260 aux.refugees3.wue] || 30B5C222F3C4 || [https://netmon.freifunk-franken.de/user.php?user_id=433 malleze_wue] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=1261 aux.refugees4.wue] || 30B5C222D3B8 || [https://netmon.freifunk-franken.de/user.php?user_id=433 malleze_wue] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=1339 aux.refugees7.wue] || 647002F71C1E || [https://netmon.freifunk-franken.de/user.php?user_id=433 malleze_wue] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=1865 aux.refugees27.wue] || 14CC20E3E9A2 || [https://netmon.freifunk-franken.de/user.php?user_id=433 malleze_wue] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=2434 aux.refugees40.wue] || 30B5C222D3B8 || [https://netmon.freifunk-franken.de/user.php?user_id=433 malleze_wue] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=1368 refugees14.wue] || C46E1F2B9B90 || [https://netmon.freifunk-franken.de/user.php?user_id=459 DiLeGreen] || 02.03.2016 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=2317 ap2.refugees.kleinheubach] || 14:cc:20:cd:4e:46 || [https://netmon.freifunk-franken.de/user.php?user_id=446 oswald] || 16.02.2016 ||<br />
<br />
|}<br />
<br />
Mehr Infos über die Aux-Firmware [https://wiki.freifunk-franken.de/w/Was_ist_die_aux_Firmware hier.]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=FF-Router_%C3%BCber_bestehendes_WLAN_kabellos_anbinden&diff=5801
FF-Router über bestehendes WLAN kabellos anbinden
2016-02-28T15:31:38Z
<p>Green: /* Editieren von /etc/config/wireless */</p>
<hr />
<div>[[Kategorie:Technik]]<br />
= Intro =<br />
Dieser Artikel beschreibt wie man einen Freifunk-Router '''drahtlos''' an einen bestehenden Router (z.B. Fritzbox, Speedport, etc..) anschliesst, um diesen so über das Internet mit dem Freifunk-Netz zu verbinden. Zwar ist ein Anschluss per Netzwerkkabel als Verbindung immer besser und auch einfacher zu realisieren, bietet aber manchmal nicht die erforderliche oder gewünschte Flexibilität beim Aufstellen des Freifunk-Routers. Weitere Gründe können sein, dass das Netzwerkkabel optisch nicht ansprechend verlegt werden kann oder dass die Netzwerkanschlüsse des Freifunk-Routers begrenzt sind und bereits für andere Zwecke gebraucht werden (Manche Modelle haben nur einen).<br />
<br />
Für den drahtlosen Anschluss eines Freifunk-Routers werden 2 Optionen präsentiert: <br />
<br />
In Option 1 wird ein zusätzlicher OpenWRT Router dazu verwendet, eine Funkverbindung mit dem Funknetz der Internetanbindung herzustellen. Dieser OpenWRT Router reicht das Internet dann an den Freifunk-Router per Netzwerkkabel weiter.<br />
<br />
In Option 2 wird der Freifunk-Router direkt mit dem Funknetz der Internetanbindung verbunden. Hierfür müssen alle beteiligten Geräte auf Kanal 1 des 2.4 GHz Bandes funken. Ferner muss der FF-Router auf Betriebssystemebene konfiguriert werden.<br />
<br />
= Option 1: Zwischengeschalteter OpenWrt Router als Brücke in das Funknetz der Internetanbindung =<br />
Ich komme immer wieder in die Situation, dass am Aufstellungsort eines FF-Routers zwar ein Internetanschluss vorhanden ist, sich aber der Internet-Router oft an den unmöglichsten Stellen befindet, ohne jede Möglichkeit den Freifunk-Router an seinem Aufstellungsort mit einem Netzwerkkabel anzuschließen. Oft ist jedoch der Internet-Router auch mit WLAN ausgestattet und bietet somit einen drahtlosen Internetzugang an. <br />
Da das Router Modell TP-Link WR841N nicht sehr teuer ist und auch noch sehr wenig Strom braucht, habe ich mir überlegt einfach einen solche Router mit OpenWrt als Accesspoint dazwischen zu schalten.<br />
<br />
Ziel ist es, dass sich der OpenWrt-Router (WR841N) das Internet-WLAN schnappt und dieses an die gelben LAN-Buchsen mit einem anderem IPv4 Netz routet.<br />
<br />
Zunächst habe ich den Router mit der aktuellen [http://wiki.openwrt.org/de/toh/tp-link/tl-wr841nd OpenWrt] Firmware geflasht, ein Passwort und einen Hostnamen und die richtige Timezone vergeben. Als nächste habe das default-WLAN gelöschen. Dies wird in der Form nicht benötigt.<br />
Danach wird ein Client-WLAN auf das zu konnektierende WLAN angelegt.<br />
In diesem Beispiel habe ich das Gast-WLAN einer Fritzbox verwendet und in ''RelayAccess'' umbenannt.<br />
Das neue Client-WLAN muss dann noch dem WAN-Port zugewiesen werden.<br />
<br />
[[Datei:Openwrt-wifi.jpg|300px|WiFi-Einstellungen]]<br />
<br />
Damit das Routing richtig funktioniert muss am WAN-Port eine feste IPv4 Adresse vergeben werden. In diesem Beispiel ist durch das Gast-WLAN der Fritzbox das IP-Netz 192.168.179.0/24 fest vorgegeben. Der DHCP-Bereich der Fritzbox geht erst bei .20 los. Ich kann in diesem Fall die Adressen von .2-.19 für statische Hosts vergeben. Da in diesem Netz sonst nichts weiter ist kann ich dem OpenWrt-Router die Adresse 192.168.179.2 fest vergeben. Als default Gateway wird die Adresse des Gast-WLANs der Fritzbox eingetragen. Der DHCP-Server darf an diesem Interface nicht aktiviert werden.<br />
<br />
[[Datei:Openwrt-wan.jpg|300px|WAN-Einstellungen]]<br />
<br />
Jetzt muss die LAN-Seite (gelbe Router-Buchsen) mit einem neuen Netzwerk eingerichtet werden. Ich habe mich der Einfachheit halber für ein Class C Netz entschieden. In diesem Fall für 192.168.180.0/24<br />
Hier braucht kein Gateway eingetragen zu werden. Der DHCP-Server muss aber eingeschaltet werden.<br />
<br />
[[Datei:Int-lan.jpg|300px|Lan-Einstellungen]]<br />
<br />
Jetzt muss noch diese Route eingetragen werden.<br />
<br />
[[Datei:Openwrt-routes..jpg|300px|Route-Einstellungen]]<br />
<br />
Vollständigkeitshalber habe ich jetzt noch der EX-WAN-Buchse (blauer Port) das ursprüngliche OpenWrt-Netz zugewiesen und auch hier den DHCP-Server aktiviert.<br />
<br />
[[Datei:Openwrt-blau.jpg|300px|Blauer Port]] <br />
<br />
An den Firewall-Zonen muss noch der markierte Parameter eingestellt werden.<br />
<br />
[[Datei:Openwrt-firewall.jpg|300px|Firewall-Einstellungen]] <br />
<br />
Die Interface Übersicht sieht dann so aus. Das Interface WAN6 kann man noch löschen wenn man möchte.<br />
<br />
[[Datei:Openwrt-interfaces.jpg|300px|Interface-Einstellungen]]<br />
<br />
Wenn sich die WLAN-Verbindung zum Internet aufgebaut hat braucht nur noch der blaue Port des FF-Routers mit einem der gelben Ports des OpenWrt-Routers mit einem Netzwerkkabel verbunden werden und wir haben einen, im Bereich des Internet-WLANs, standortunabhängigen Freifunk-Router ohne ein lästiges Netzwerkkabel verlegen zu müssen. <br />
<br />
'''Weitere Tipps:'''<br />
<br />
* Wie man einen FF-Router an einem Fritzbox Gastzugang betreibt steht [[FF-Router am Gastzugang einer Fritzbox|hier]]:<br />
* Man sollte darauf achten, dass das Internet-WLAN auf Kanal 6 oder 11 eingestellt ist. Da die beiden TP-Link Router wahrscheinlich sehr dicht nebeneinander stehen ist eine gegenseitige Störung bei gleicher Kanaleinstellung von FF-WLAN ind Internet-WLAN nicht ausgeschlossen. Freifunk ist immer auf Kanal 1.<br />
<br />
= Option 2: Direktes Einbinden des Freifunk-Routers in das Funknetz der Internetanbindung =<br />
<br />
In Option 2 bindet man den Freifunk-Router direkt und drahtlos in das Funknetz einer bestehenden Internetverbindung ein.<br />
<br />
Dieses Vorgehen wurde bislang mit folgender Hardware/ Software Kombination erfolgreich durchgeführt:<br />
* Ubiquiti Nanostation M2 Loco (Firmware 0.5.1) an AVM Fritz!Box 7360 (Fritz!OS 6.30)<br />
* TP-Link WR-841n(d) V9 (Firmware 0.5.1) an AVM Fritz!Box 7360 (Fritz!OS 6.30)<br />
<br><br />
== Voraussetzungen ==<br />
* Sicheres [[Anleitungen|Passwort]] auf dem Freifunk Router ("Wie ändere ich das Passwort für den Router?")<br />
* [[Anleitungen|SSH Zugriff]] auf den Router ("Wie kann ich mich auf den Router einloggen?")<br />
* Zugriff auf den Router des Funknetzes der Internetanbindung <br />
* Kenntnis von SSID (Funknetzname), Key (Password) und Encryption (Verschlüsselungsverfahren) des Funknetzes der Internetanbindung <br />
* Router des Funknetzes der Internetanbindung arbeitet auf dem gleichen Kanal wie der Freifunk-Router, d.h. der Router des Funknetzes der Internetanbindung ist auf '''Kanal 1''' des 2.4 GHz Bandes konfiguriert.<br />
<br><br />
== Einloggen ==<br />
Zunächst muss man sich mit dem FF-Router verbinden. Da im Regelfall automatisiert eine IP von einem Gateway bezogen wird, ist dies am einfachsten, wenn der Freifunk-Router<br />
* temporär per Netzwerkkabel an einen Router mit Internetzugang angeschlossen wird<br />
* bereits drahtlos in das Freifunk-Netz eingebunden ist (indem er z.B. in der Nähe eines anderen Freifunk-Routers steht)<br />
<br />
Alternativ kann man auch ohne Internetverbindung Zugriff auf den Freifunk-Router erlangen, indem man für die SSID franken.freifunk.net manuell eine beliebige IP (z.B. 1.2.3.4) und eine Netzmaske (z.B. 255.255.255.0) vorgibt und sich in unmittelbarer Nähe des Routers verbindet. Eine IP muss dann nicht mehr aus dem Internet bezogen werden. <br />
<br />
Dann [[Anleitungen|loggt]] man sich auf dem Router per ssh ein.<br />
<br><br />
== Konfiguration ==<br />
=== Sicherheitskopien ===<br />
Zunächst sind Sicherheitskopien der später veränderten Dateien empfehlenswert:<br />
<code><br />
cp /etc/config/network /etc/config/network.orig<br />
<br />
cp /etc/config/wireless /etc/config/wireless.orig<br />
<br />
cp /etc/config/firewall /etc/config/firewall.orig <br />
<br />
cp /etc/config/nodewatcher /etc/config/nodewatcher.orig<br />
</code><br />
<br />
<br />
Falls später gewünscht, ist ein Zurückspielen der gesicherten Konfiguration umgekehrt über<br />
<code><br />
cp /etc/config/network.orig /etc/config/network <br />
<br />
cp /etc/config/wireless.orig /etc/config/wireless <br />
<br />
cp /etc/config/firewall.orig /etc/config/firewall<br />
<br />
cp /etc/config/nodewatcher.orig /etc/config/nodewatcher<br />
</code><br />
möglich.<br />
<br><br />
=== Editieren von /etc/config/network ===<br />
Mittels eines Texteditors muss an die vorhandene Konfigurationsdatei /etc/config/network ein Konfigurationsblock '''angefügt''' werden. Die bestehenden Konfigurationsblöcke müssen erhalten bleiben.<br />
<br />
Aufruf des Texteditors:<br />
<code><br />
vi /etc/config/network<br />
</code><br />
<br />
<br />
Mittels "i" kann der Editor in den Einfügemodus versetzt werden. Folgender Konfigurationsblock sollte am Ende der Datei angefügt werden.<br />
<br />
<pre><br />
config interface 'wwan'<br />
option proto 'dhcp'<br />
</pre><br />
<br />
Es wird ein neues Interface definiert, dass für die Funkverbindung zum Router mit Internetanbindung verwendet wird.<br />
<br />
Mit "Esc" beendet man den Einfügemodus. Mit ":x" speichert man die Datei. Mit ":q!" verwirft man die Änderungen, falls etwas schief gegangen sein sollte. Der [http://org.netbase.org/vi.html Editor] wird in beiden Fällen beendet.<br />
<br />
Info: Weitere Konfigurationsmöglichkeiten sind [http://wiki.openwrt.org/doc/uci/network hier] dokumentiert.<br />
<br><br />
=== Editieren von /etc/config/wireless ===<br />
Auch hier muss die Konfiguration mittels Texteditor angepasst werden:<br />
<br />
<code><br />
vi /etc/config/wireless<br />
</code><br />
<br />
Wieder muss der [http://org.netbase.org/vi.html Texteditor] mit "i" in den Einfügemodus versetzt werden und folgender Konfigurationsblock '''angefügt''' werden. Die bestehenden Einträge müssen erhalten bleiben.<br />
<pre><br />
config wifi-iface<br />
option ssid 'SSID_des_Wlan_Routers'<br />
option encryption 'psk2' # Set wep, psk or psk2 for WEP, WPA or WPA2 <br />
option device 'radio0'<br />
option mode 'sta'<br />
option network 'wwan'<br />
option ifname 'wwan'<br />
option key 'Key_des_Wlan_Routers'<br />
</pre><br />
<br />
<br />
Hier werden die Konfigurationsparameter des Funknetzes eingefügt, mit denen sich der Freifunk-Router verbinden soll, um die Internetanbindung zu realisieren. Neben dem Namen des Funknetzes ('''ssid''') und dem Password / Verschlüsselungscode ('''key''') sollte hier das Verschlüsselungsverfahren ('''encryption''') ''angepasst werden''. Die Zugangsdaten werden benötigt, damit der Freifunk-Router Zugriff auf das Funknetz der Internetanbindung nehmen kann.<br />
<br />
Darüber hinaus muss das Funknetz der Internetanbindung wie der Freifunk-Router auf '''Kanal 1''' des 2.4 GHz Bandes funken. Dies muss ggf. in der Konfiguration des Routers der Internetanbindung geändert werden.<br />
<br />
Der Name des Funk-Devices "radio0" sollte bereits in den bestehenden Konfigurationsblöcken von /etc/config/wireless erwähnt sein.<br />
<br />
Mit "Esc" beendet man den Einfügemodus. Mit ":x" speichert man die Datei. Mit ":q!" verwirft man die Änderungen, falls etwas schief gegangen sein sollte. Der [http://org.netbase.org/vi.html Editor] wird in beiden Fällen beendet.<br />
<br />
Info: Weitere Konfigurationsmöglichkeiten sind [http://wiki.openwrt.org/doc/uci/wireless hier] dokumentiert.<br />
<br><br />
<br />
=== Editieren von /etc/config/firewall ===<br />
Auch hier muss die Konfiguration mittels Texteditor angepasst werden:<br />
<br />
<code><br />
vi /etc/config/firewall<br />
</code><br />
<br />
<br />
Wieder muss der [http://org.netbase.org/vi.html Texteditor] mit "i" in den Einfügemodus versetzt werden und folgende Konfigurationsblöcke '''angefügt''' werden. Das neu erstellte Netzwerk muss in die wan Zone der firewall eingebracht werden. Hierfür muss folgender Konfigurationsblock angepasst werden: <br />
<pre><br />
config zone<br />
option name wan<br />
option input REJECT<br />
option output ACCEPT<br />
option forward REJECT<br />
option masq 1<br />
option mtu_fix 1<br />
option network 'wan wwan'<br />
<br />
</pre><br />
<br />
<br />
Mit "Esc" beendet man den Einfügemodus. Mit ":x" speichert man die Datei. Mit ":q!" verwirft man die Änderungen, falls etwas schief gegangen sein sollte. Der Editor wird in beiden Fällen beendet.<br />
<br><br />
=== Ausblenden des neuen Interfaces im Netmon (optional) ===<br />
Wir editieren die Datei nodewatcher:<br />
<code><br />
vi /etc/config/nodewatcher<br />
</code><br />
<br />
Und tragen das oben neu definierten Interface wwan in die Blacklist der Interfaces ein, die nicht an den Netmon durchgereicht werden.<br />
Mittels "i" kann der Editor in den Einfügemodus versetzt werden. Folgender Konfigurationsblock kann angepasst werden:<br />
<pre><br />
config network<br />
option mesh_interface 'br-mesh'<br />
option iface_blacklist 'lo ifb0 wwan'<br />
option ip_whitelist 'br-mesh'<br />
option client_interfaces 'w2ap'<br />
</pre><br />
<br />
<br />
Mit "Esc" beendet man den Einfügemodus. Mit ":x" speichert man die Datei. Mit ":q!" verwirft man die Änderungen, falls etwas schief gegangen sein sollte. Der Editor wird in beiden Fällen beendet.<br />
<br><br />
=== Reboot und Aufstellen des Freifunk Routers ===<br />
Die Änderungen werden nach Neustart des Routers aktiv:<br />
<code><br />
reboot & exit<br />
</code><br />
<br />
Der Router kann nach dem Neustart an seinen Aufstellungsort gebracht werden (falls er temporär woanders angeschlosssen war) und dort eingeschaltet werden.<br />
<br><br />
== Abschlusscheck der Konfiguration ==<br />
Am neuen Aufstellungsort sollte der Freifunk-Router sich selbstständig und drahtlos zu dem vorkonfigurierten Funknetz verbinden.<br />
<br />
Wir verbinden uns mit dem Router und [[Anleitungen|loggen]] uns ein.<br />
<br />
Nach Aufruf von ...<br />
<code><br />
route<br />
</code><br />
<br />
...sollte eine default-Route über das neu erstellte Interface wwan zum verbundenen Netzwerk sichtbar werden. Exemplarisch:<br />
<pre><br />
Kernel IP routing table<br />
Destination Gateway Genmask Flags Metric Ref Use Iface<br />
default fritz.box 0.0.0.0 UG 0 0 0 wwan<br />
192.168.178.0 * 255.255.255.0 U 0 0 0 wwan<br />
</pre><br />
<br />
<br />
Über...<br />
<code><br />
iwconfig wwan<br />
</code><br />
<br />
...kann man das Funknetz anzeigen, mit dem sich der FF-Router verbunden hat. Exemplarisch:<br />
<pre><br />
wwan IEEE 802.11bgn ESSID:"SSID_des_Wlan_Routers" <br />
Mode:Managed Frequency:2.412 GHz Access Point: 34:81:C4:7A:3C:18 <br />
Bit Rate=24 Mb/s Tx-Power=22 dBm <br />
RTS thr:off Fragment thr:off<br />
Encryption key:off<br />
Power Management:off<br />
Link Quality=31/70 Signal level=-75 dBm <br />
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0<br />
Tx excessive retries:9 Invalid misc:8293 Missed beacon:0<br />
</pre><br />
<br />
Hier sollte als Access Point die MAC-Adresse des Routers eingetragen sein, von dem man das Internet bezieht. Wenn man nennenswerte Datenraten erzielen möchte, sollte die Signalstärke nicht unter -75 dBm liegen.<br />
<br />
Der fastd Prozess zum Aufbau eines VPN-Tunnels ins Freifunknetz sollte gestartet sein. Der Aufruf...<br />
<code><br />
pgrep fastd<br />
</code><br />
...sollte mit der ID des fastd-Prozesses beantwortet werden.<br />
<br />
Die Rückmeldungen über die Einbindung in das Funknetz der Internetanbindung kann man sich über...<br />
<code><br />
dmesg | grep wwan<br />
</code><br />
<br />
...anzeigen lassen. Exemplarisch:<br />
<pre><br />
[ 26.440000] IPv6: ADDRCONF(NETDEV_UP): wwan: link is not ready<br />
[ 28.060000] wwan: authenticate with 34:81:c4:7a:3c:18<br />
[ 28.070000] wwan: send auth to 34:81:c4:7a:3c:18 (try 1/3)<br />
[ 28.080000] wwan: authenticated<br />
[ 28.090000] wwan: associate with 34:81:c4:7a:3c:18 (try 1/3)<br />
[ 28.100000] wwan: RX AssocResp from 34:81:c4:7a:3c:18 (capab=0x31 status=0 aid=2)<br />
[ 28.100000] wwan: associated<br />
[ 28.110000] IPv6: ADDRCONF(NETDEV_CHANGE): wwan: link becomes ready<br />
</pre><br />
<br />
<br />
Ist '''keine''' Verbindung zum Freifunk-Router möglich, bezieht man evtl. keine IP, da die Internetanbindung nicht funktioniert. Die wahrscheinlichsten Ursachen hierfür sind:<br />
* Der Freifunk Router befindet sich an seinem neuen Standort nicht in Reichweite des Funknetzes, an das er angeschlossen werden soll<br />
* Der Freifunk Router kann keine Verbindung zum Funknetz der Internetanbindung aufbauen. Hier sollte man nochmal die Parameter ssid, key und encryption in /etc/config/wireless prüfen als auch sicherstellen, dass beide Funknetze (Internetanbindung & Freifunk) auf Kanal 1 arbeiten.<br />
* Der fastd VPN-Tunnel wird erstmalig gestartet und benötigt noch etwas Zeit. Als absolute Obergrenze kann man bis zu 10 Minuten warten. Evtl. hilft auch ein Neustart des Routers.<br />
<br />
'''Hinweis:''' Man kann zu Diagnosezwecken auch ohne Internetverbindung Zugriff auf den Freifunk-Router erlangen, indem man für die SSID franken.freifunk.net manuell eine beliebige IP (z.B. 1.2.3.4) und eine Netzmaske (z.B. 255.255.255.0) vorgibt und sich in unmittelbarer Nähe des Routers verbindet. Eine IP muss dann nicht mehr aus dem Internet bezogen werden.</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Server&diff=5749
Server
2016-02-25T19:47:38Z
<p>Green: /* Gateway Server "kleeV2" */</p>
<hr />
<div>{{Entwurf}}<br />
<br />
__TOC__<br />
<br />
= Gateway Server = <br />
<br />
== Gateway Server fff-fra1 ==<br />
<br />
[[Server/fff-fra1|Details gibts hier...]]<br />
<br />
== Gateway Server "ro1" ==<br />
'''IP/Domain:''' ???<br />
<br />
'''Standort:''' Rumänien<br />
<br />
'''Owner:''' [[Benutzer:TheFroggy]]<br />
<br />
'''OLSR-Infos:''' [http://10.50.32.1:8080/all http://10.50.32.1:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''Admins:'''<br />
* [[Benutzer:RedDog]] <br />
* [[Benutzer:Casandro]]<br />
* [[Benutzer:Magenbrot]]<br />
<br />
'''Funktion:'''<br />
* Internet Uplink (direkt)<br />
* DNS<br />
* ICVPN Knoten<br />
* Jabber<br />
* IPIP Tunnel zu anderen GWs<br />
* IPv4 Gateway (dhcp) für<br />
** Default-Hood<br />
** Fürth<br />
** Nürnberg<br />
** Ansbach<br />
** Erlangen<br />
<br />
'''Monitoring'''<br />
* URL: https://monitor.ovtec.de/icinga/<br />
* User: freifunk_ro<br />
* Pass: TeUa-w8q_o6wUh4ZuW<br />
<br />
== Gateway Server "fff-nue1" ==<br />
'''IP/Domain:''' fff-nue1.wavecloud.de<br />
<br />
'''Standort:''' Nürnberg<br />
<br />
'''Owner:''' wavecloud.de<br />
<br />
'''OLSR-Infos:''' [http://10.50.32.2:8080/all http://10.50.32.2:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''Admins'''<br />
* [[Benutzer:Magenbrot]]<br />
* [[Benutzer:DelphiN]]<br />
* [[Benutzer:Corny]]<br />
* [[Benutzer:RedDog]]<br />
<br />
'''Funktion:'''<br />
* Key-Exchange-Server: [http://keyserver.freifunk-franken.de/fff/ keyserver.freifunk-franken.de]<br />
* Internet Uplink (vpn03 [Freie Netze eV])<br />
* DNS<br />
* IPIP Tunnel zu ro1<br />
* IPIP Tunnel zu fff-has<br />
* IPv4 Gateway (dhcp) für<br />
** Default-Hood<br />
** Fürth<br />
** Ansbach<br />
** Erlangen<br />
** Würzburg<br />
<br />
== Gateway Server "fff-uk1" ==<br />
'''IP/Domain:''' ???<br />
<br />
'''Standort:''' UK<br />
<br />
'''Owner:''' [[Benutzer:RedDog]]<br />
<br />
'''OLSR-Infos:''' <strike>[http://10.50.32.3:8080/all http://10.50.32.3:8080/all] (Nur Freifunk-Intern)</strike><br />
<br />
'''Admins'''<br />
* [[Benutzer:RedDog]]<br />
* Meskal<br />
<br />
'''Funktion:'''<br />
* Internet Uplink (direkt)<br />
* DNS<br />
* IPv6 Gateway für<br />
** Fürth<br />
<br />
== Gateway Server "fff-has" ==<br />
'''IP/Domain:''' ???<br />
<br />
'''Standort:''' Falkenstein<br />
<br />
'''Owner:''' [[Benutzer:Moexe]]<br />
<br />
'''OLSR-Infos:''' [http://10.50.40.3:8080/all http://10.50.40.3:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''Traffic-Statistic [http://10.50.56.3 MRTG] ''' (Nur Freifunk-Intern)<br />
<br />
'''Admins'''<br />
* [[Benutzer:Moexe]]<br />
'''Funktion:'''<br />
* VPN über Mullvad nach Holland<br />
* IPIP Tunnel zu ro1<br />
* IPIP Tunnel zu fff-nue1<br />
* IPIP Tunnel zu fff-has2<br />
* IPIP Tunnel zu fff-wue1<br />
* IPIP Tunnel zu roffl<br />
<br />
* IPv4 Gateway (dhcp) für<br />
** Haßberge<br />
** Haßberge Süd<br />
<br />
== Gateway Server "fff-has2" ==<br />
'''IP/Domain:''' 5.196.164.9<br />
<br />
'''Standort:''' Frankfurt<br />
<br />
'''Owner:''' [[Benutzer:Plocker]]<br />
<br />
'''OLSR-Infos:''' [http://10.50.56.4:8080/all http://10.50.56.4:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''mrtg-Infos:''' [http://10.50.56.4 http://10.50.56.4] (Nur Freifunk-Intern)<br />
<br />
'''Admins'''<br />
*[[Benutzer:Plocker]] <br />
*[[Benutzer:Moexe]]<br />
<br />
'''Funktion:'''<br />
* VPN über Mullvad nach Holland<br />
* IPIP Tunnel zu ro1<br />
* IPIP Tunnel zu fff-nue1<br />
* IPIP Tunnel zu fff-has<br />
* IPIP Tunnel zu fff-wue1<br />
* IPIP Tunnel zu fff-gw-cdfue1<br />
* IPIP Tunnel zu fff-mayo<br />
* IPIP Tunnel zu fff-roffl<br />
* IPv4 Gateway (dhcp) für<br />
** Haßberge<br />
** Haßberge Süd<br />
**<strike>Nürnberg</strike><br />
<br />
== Gateway Server "fff-roffl" ==<br />
'''IP/Domain:''' 176.123.28.108<br />
<br />
'''Standort:''' Frankfurt<br />
<br />
'''Owner:''' [[Benutzer:roffl1990]]<br />
<br />
'''OLSR-Infos:''' [http://10.50.60.7:8080/all http://10.50.60.7:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''Admins'''<br />
*[[Benutzer:roffl1990]] <br />
*[[Benutzer:Plocker]] <br />
*[[Benutzer:Moexe]]<br />
<br />
'''Funktion:'''<br />
* IPIP Tunnel zu pi<br />
* IPIP Tunnel zu fff-has<br />
* IPIP Tunnel zu fff-has<br />
* IPv4 Gateway (dhcp) für<br />
** Haßberge<br />
** Haßberge Süd<br />
<br />
== Gateway Server "watzmann" ==<br />
'''IP/Domain:''' 10.50.80.1<br />
<br />
'''Standort:''' Webhod Networks GbR, Frankfurt<br />
<br />
'''Owner:''' [[Benutzer:mrtnschn]]<br />
<br />
<br />
'''OLSR-Infos:''' [http://10.50.60.1:8080/all http://10.50.60.1:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''Admins'''<br />
*[[Benutzer:Fffbamberg]] <br />
<br />
<br />
'''Funktion:'''<br />
* VPN über Cyberghost nach Holland<br />
* IPv4 Gateway (dhcp) für<br />
** Bamberg<br />
<br />
== Gateway Server "kleeV2" ==<br />
'''IP/Domain:''' 10.50.72.7<br />
<br />
'''Standort:''' Amsterdam / Niederlande<br />
<br />
'''Owner:''' [[Benutzer:Green]]<br />
<br />
<br />
'''Übersicht / Statistiken:''' [http://kleev2.gw.fff.community http://kleev2.gw.fff.community] (nur Freifunk intern)<br />
<br />
'''OLSR-Infos:''' [http://kleev2.gw.fff.community:8080/all http://kleev2.gw.fff.community:8080/all] (nur Freifunk intern)<br />
<br />
'''Admins:'''<br />
* [[Benutzer:Green]]<br />
<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via OpenVPN (Mullvad)<br />
* DNS (Freifunk Static Stub Konfiguration + InterCityVPN DNS)<br />
* IPIP Tunnel zu anderen GWs (ro1, nue1, bbg, cdfue1, has2, fra1)<br />
* IPv4 Gateway (dhcp) für<br />
** Aux<br />
** Würzburg<br />
<br />
== Gateway Server "fff-gw-cd1" ==<br />
'''IP/Domain:''' fff-gw-cd1.fff.community<br />
<br />
'''Standort:''' Falkenstein - Hetzner<br />
<br />
'''Owner:''' [[Benutzer:ChristianD]]<br />
<br />
<br />
'''Admins:'''<br />
* [[Benutzer:ChristianD]]<br />
<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via OpenVPN (Mullvad)<br />
* GRE-Tunnel für OSLR zu anderen Gateways (kleeV2, fff-gw-m1, has2, ro1, fff-pi-cd1)<br />
* IPv4 Internetgateway (dhcp) für<br />
** Fürth 'fff-gw-cdfue1'<br />
** Ansbach 'fff-gw-cdan1'<br />
** NbgLand 'fff-gw-cdnbgland1'<br />
* Client in Nürnberg zur Routerfernwartung außerhalb der eigenen Hood 'fff-gw-cdnue1'<br />
* nbgland Internettraffic wird über fff-pi-cd1 ins Internet geroutet [http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/2016-January/002417.html Mehr Infos]<br />
* Owncloud Server (Testbetrieb URL folgt...)<br />
* webbasiertes Forum (Testbetrieb URL folgt...)<br />
<br />
'''Statistiken:'''<br />
* Statistiken: [http://fff-gw-cd1.fff.community/index.php http://fff-gw-cd1.fff.community/index.php]<br />
<br />
== Internet Exit Server "fff-pi-cd1" ==<br />
'''IP/Domain:''' folgt<br />
<br />
'''Standort:''' [http://raspberry-host.de/ Raspberry Host]<br />
<br />
'''Owner:''' [[Benutzer:ChristianD]]<br />
<br />
<br />
'''Admins:'''<br />
* [[Benutzer:ChristianD]]<br />
<br />
'''Funktion:'''<br />
* Internetexit über Mullvad<br />
<br />
'''Statistiken:'''<br />
* [http://37.228.135.203/vnstat/ vnstat]<br />
<br />
== Gateway Server "fff-wue1" ==<br />
''' IP/Domain:''' 10.50.72.6<br />
<br />
''' Standort:''' Falkenstein (Hetzner)<br />
<br />
'''Owner:''' [[Benutzer:mifritscher]]<br />
<br />
<br />
'''Admins:'''<br />
* [[Benutzer:mifritscher]]<br />
<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via OpenVPN (Mullvad, Niederlande)<br />
* GRE-Tunnel für OSLR zu anderen Gateways <br />
** fff-has (10.50.72.3)<br />
** fff-has2 (10.50.56.3)<br />
** fff-has3 (10.50.56.6; per IPv6) - derzeit deaktiviert<br />
* IPv4 Internetgateway (dhcp) für<br />
** Würzburg<br />
** Nürnberg<br />
** Nbg-Land<br />
<br />
'''Statistiken:'''<br />
* Allgemeine Statistik zum Server: [http://188.40.170.116/monitoring/i.html]<br />
* Auslastung und Traffic Statistik: [http://10.50.72.6/mrtg http://10.50.72.6/mrtg] (nur Freifunk intern) oder [http://188.40.170.116/mrtg http://188.40.170.116/mrtg]<br />
* OLSR-Infos: [http://10.50.72.6:8080/all http://10.50.72.6:8080/all] (nur Freifunk intern) oder [http://188.40.170.116:8080/all http://188.40.170.116:8080/all]<br />
<br />
''' Hinweise '''<br />
Der Server wurde nach [[Freifunk-Gateway_aufsetzen]] aufgesetzt, die Statistik-Seite nach [[Portal:Netz/Statistiken]] erstellt.<br />
<br />
== Gateway Server "FFF-GW-M1" ==<br />
<br />
''' IP/Domain:''' 10.50.40.10<br />
<br />
''' Standort:''' Deutschland (netcup)<br />
<br />
'''Owner:''' [[Benutzer:mayosemmel]]<br />
<br />
<br />
'''Admins:'''<br />
* [[Benutzer:mayosemmel]]<br />
<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via OpenVPN (Mullvad, Land wechselnd je nach Performance)<br />
* Gateway zum IC-VPN [https://wiki.freifunk.net/IC-VPN]<br />
* GRE-Tunnel für OSLR zu anderen Gateways <br />
* IPv4 Internetgateway (dhcp) für<br />
** Nürnberg<br />
<br />
'''Statistiken:'''<br />
* OLSR-Infos: [http://10.50.40.10:8080/all http://10.50.40.10:8080/all] (nur Freifunk intern)<br />
* Weitere Statistiken: [http://10.50.40.10 http://10.50.40.10] (nur Freifunk intern)<br />
<br />
== Gateway Server "fff-gw-yaga" ==<br />
''' IP/Domain:''' 10.50.40.7<br />
<br />
''' Standort:''' Düsseldorf<br />
<br />
'''Owner:''' [[Benutzer:yaga]]<br />
<br />
'''OLSR-Infos:''' [http://10.50.40.7:8080/all http://10.50.40.7:8080/all] (nur Freifunk intern)<br />
<br />
'''Admins:'''<br />
* [[Benutzer:yaga]]<br />
<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via OpenVPN (privateinternetaccess, Holland)<br />
* GRE-Tunnel für OLSR zu anderen Gateways <br />
** fff-wue1 (10.50.252.22 <-> 10.50.252.23)<br />
** ro1 (10.50.252.40 <-> 10.50.252.41)<br />
** nue1 (10.50.252.42 <-> 10.50.252.43)<br />
* IPv4 Internetgateway (dhcp) für<br />
** Nürnberg<br />
** Erlangen<br />
<br />
== Gateway Server "fff-bbg" ==<br />
'''IP/Domain:''' 78.46.181.112/bbg.meskalero.de<br />
<br />
'''Standort:''' Falkenstein - Hetzner<br />
<br />
'''Owner:''' [[Benutzer:meskal]]<br />
<br />
'''Admins:'''<br />
* [[Benutzer:meskal]]<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via olsr-Layer3 meshing<br />
* GRE-Tunnel für OLSR zu anderen Gateways <br />
** fff-fra1<br />
** fff-ro1<br />
** fff-nue1<br />
** fff-wue1<br />
** fff-has2<br />
** fff-klee<br />
* IPv4 Internetgateway (dhcp) für<br />
** Nürnberg<br />
** aux<br />
'''Statistik'''<br />
** http://bbg.meskalero.de/CGP/host.php?h=bbg.meskalero.de<br />
<br />
== Gateway Server "fff-kwadro" ==<br />
'''IP/Domain:''' 78.46.210.151<br />
<br />
'''Standort:''' Hetzner<br />
<br />
'''Owner:''' [[Benutzer:Kwadronaut]]<br />
<br />
'''Admins:'''<br />
* [[Benutzer:Kwadronaut]]<br />
<br />
'''Funktion:'''<br />
* GRE-Tunnel für OLSR zu anderen Gateways <br />
** fff-staufen<br />
** fff-ro1<br />
** fff-nue1<br />
** fff-watzmann<br />
** fff-cd1<br />
** fff-m1<br />
* IPv4 Internetgateway (dhcp) für<br />
** Erlangen (geplant)<br />
'''Statistik'''<br />
** sollte ich mal bauen<br />
<br />
= Sonstige Server =<br />
<br />
== Netmon Server "fff-netmon1" ==<br />
'''IP/Domain:''' fff-netmon1.wavecloud.de<br />
<br />
'''Standort:''' Nürnberg<br />
<br />
'''Owner:''' wavecloud.de<br />
<br />
'''Admins'''<br />
* [[Benutzer:Magenbrot]]<br />
* [[Benutzer:RedDog]]<br />
* Meskal<br />
* mrtnmb<br />
<br />
'''Funktion:'''<br />
* Netmon<br />
* ntdp<br />
* Keyxchange (/var/www/keyserver/fff/)<br />
<br />
== Webserver "fff_wiki1" ==<br />
'''IP/Domain:''' odin.ovtec.it<br />
<br />
'''Standort:''' Nürnberg<br />
<br />
'''Owner:''' [[Benutzer:magenbrot]]<br />
<br />
'''Admins'''<br />
* [[Benutzer:magenbrot]]<br />
<br />
'''Funktion:'''<br />
* [https://wiki.freifunk-franken.de wiki.freifunk.franken.de]<br />
* [http://ftp.freifunk-franken.de ftp.freifunk-franken.de]<br />
<br />
== LibreMapFranken ==<br />
'''IP/Domain:''' 95.85.40.145<br />
<br />
'''Type:''' VM (1GB Ram, 20GB SSD Disk, Ubuntu 13.04 x64)<br />
<br />
'''Standort:''' [http://speedtest-ams2.digitalocean.com/ Amsterdam]<br />
<br />
'''Owner:''' [[Benutzer:delphiN]]<br />
<br />
'''Admins'''<br />
* [[Benutzer:delphiN]]<br />
* Roland Greim<br />
<br />
'''Funktion:'''<br />
* [http://libremap.freifunk-franken.de:5984/libremap-dev/_design/libremap-webui/index.html libremap.freifunk-franken.de]<br />
* [https://github.com/FreifunkFranken/community.franken.freifunk.net/blob/master/updateFromNetmon.sh regelmäßige Updates der community api]<br />
<br />
== fff-nue2.fff.community ==<br />
* Host-System für versch. VMs:<br />
** todo ..<br />
<br />
Siehe auch [[Server/fff-nue2]]<br />
<br />
[[Kategorie:Technik]]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Server&diff=5745
Server
2016-02-25T19:34:03Z
<p>Green: /* Gateway Server "kleeV2" */</p>
<hr />
<div>{{Entwurf}}<br />
<br />
__TOC__<br />
<br />
= Gateway Server = <br />
<br />
== Gateway Server fff-fra1 ==<br />
<br />
[[Server/fff-fra1|Details gibts hier...]]<br />
<br />
== Gateway Server "ro1" ==<br />
'''IP/Domain:''' ???<br />
<br />
'''Standort:''' Rumänien<br />
<br />
'''Owner:''' [[Benutzer:TheFroggy]]<br />
<br />
'''OLSR-Infos:''' [http://10.50.32.1:8080/all http://10.50.32.1:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''Admins:'''<br />
* [[Benutzer:RedDog]] <br />
* [[Benutzer:Casandro]]<br />
* [[Benutzer:Magenbrot]]<br />
<br />
'''Funktion:'''<br />
* Internet Uplink (direkt)<br />
* DNS<br />
* ICVPN Knoten<br />
* Jabber<br />
* IPIP Tunnel zu anderen GWs<br />
* IPv4 Gateway (dhcp) für<br />
** Default-Hood<br />
** Fürth<br />
** Nürnberg<br />
** Ansbach<br />
** Erlangen<br />
<br />
'''Monitoring'''<br />
* URL: https://monitor.ovtec.de/icinga/<br />
* User: freifunk_ro<br />
* Pass: TeUa-w8q_o6wUh4ZuW<br />
<br />
== Gateway Server "fff-nue1" ==<br />
'''IP/Domain:''' fff-nue1.wavecloud.de<br />
<br />
'''Standort:''' Nürnberg<br />
<br />
'''Owner:''' wavecloud.de<br />
<br />
'''OLSR-Infos:''' [http://10.50.32.2:8080/all http://10.50.32.2:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''Admins'''<br />
* [[Benutzer:Magenbrot]]<br />
* [[Benutzer:DelphiN]]<br />
* [[Benutzer:Corny]]<br />
* [[Benutzer:RedDog]]<br />
<br />
'''Funktion:'''<br />
* Key-Exchange-Server: [http://keyserver.freifunk-franken.de/fff/ keyserver.freifunk-franken.de]<br />
* Internet Uplink (vpn03 [Freie Netze eV])<br />
* DNS<br />
* IPIP Tunnel zu ro1<br />
* IPIP Tunnel zu fff-has<br />
* IPv4 Gateway (dhcp) für<br />
** Default-Hood<br />
** Fürth<br />
** Ansbach<br />
** Erlangen<br />
** Würzburg<br />
<br />
== Gateway Server "fff-uk1" ==<br />
'''IP/Domain:''' ???<br />
<br />
'''Standort:''' UK<br />
<br />
'''Owner:''' [[Benutzer:RedDog]]<br />
<br />
'''OLSR-Infos:''' <strike>[http://10.50.32.3:8080/all http://10.50.32.3:8080/all] (Nur Freifunk-Intern)</strike><br />
<br />
'''Admins'''<br />
* [[Benutzer:RedDog]]<br />
* Meskal<br />
<br />
'''Funktion:'''<br />
* Internet Uplink (direkt)<br />
* DNS<br />
* IPv6 Gateway für<br />
** Fürth<br />
<br />
== Gateway Server "fff-has" ==<br />
'''IP/Domain:''' ???<br />
<br />
'''Standort:''' Falkenstein<br />
<br />
'''Owner:''' [[Benutzer:Moexe]]<br />
<br />
'''OLSR-Infos:''' [http://10.50.40.3:8080/all http://10.50.40.3:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''Traffic-Statistic [http://10.50.56.3 MRTG] ''' (Nur Freifunk-Intern)<br />
<br />
'''Admins'''<br />
* [[Benutzer:Moexe]]<br />
'''Funktion:'''<br />
* VPN über Mullvad nach Holland<br />
* IPIP Tunnel zu ro1<br />
* IPIP Tunnel zu fff-nue1<br />
* IPIP Tunnel zu fff-has2<br />
* IPIP Tunnel zu fff-wue1<br />
* IPIP Tunnel zu roffl<br />
<br />
* IPv4 Gateway (dhcp) für<br />
** Haßberge<br />
** Haßberge Süd<br />
<br />
== Gateway Server "fff-has2" ==<br />
'''IP/Domain:''' 5.196.164.9<br />
<br />
'''Standort:''' Frankfurt<br />
<br />
'''Owner:''' [[Benutzer:Plocker]]<br />
<br />
'''OLSR-Infos:''' [http://10.50.56.4:8080/all http://10.50.56.4:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''mrtg-Infos:''' [http://10.50.56.4 http://10.50.56.4] (Nur Freifunk-Intern)<br />
<br />
'''Admins'''<br />
*[[Benutzer:Plocker]] <br />
*[[Benutzer:Moexe]]<br />
<br />
'''Funktion:'''<br />
* VPN über Mullvad nach Holland<br />
* IPIP Tunnel zu ro1<br />
* IPIP Tunnel zu fff-nue1<br />
* IPIP Tunnel zu fff-has<br />
* IPIP Tunnel zu fff-wue1<br />
* IPIP Tunnel zu fff-gw-cdfue1<br />
* IPIP Tunnel zu fff-mayo<br />
* IPIP Tunnel zu fff-roffl<br />
* IPv4 Gateway (dhcp) für<br />
** Haßberge<br />
** Haßberge Süd<br />
**<strike>Nürnberg</strike><br />
<br />
== Gateway Server "fff-roffl" ==<br />
'''IP/Domain:''' 176.123.28.108<br />
<br />
'''Standort:''' Frankfurt<br />
<br />
'''Owner:''' [[Benutzer:roffl1990]]<br />
<br />
'''OLSR-Infos:''' [http://10.50.60.7:8080/all http://10.50.60.7:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''Admins'''<br />
*[[Benutzer:roffl1990]] <br />
*[[Benutzer:Plocker]] <br />
*[[Benutzer:Moexe]]<br />
<br />
'''Funktion:'''<br />
* IPIP Tunnel zu pi<br />
* IPIP Tunnel zu fff-has<br />
* IPIP Tunnel zu fff-has<br />
* IPv4 Gateway (dhcp) für<br />
** Haßberge<br />
** Haßberge Süd<br />
<br />
== Gateway Server "watzmann" ==<br />
'''IP/Domain:''' 10.50.80.1<br />
<br />
'''Standort:''' Webhod Networks GbR, Frankfurt<br />
<br />
'''Owner:''' [[Benutzer:mrtnschn]]<br />
<br />
<br />
'''OLSR-Infos:''' [http://10.50.60.1:8080/all http://10.50.60.1:8080/all] (Nur Freifunk-Intern)<br />
<br />
'''Admins'''<br />
*[[Benutzer:Fffbamberg]] <br />
<br />
<br />
'''Funktion:'''<br />
* VPN über Cyberghost nach Holland<br />
* IPv4 Gateway (dhcp) für<br />
** Bamberg<br />
<br />
== Gateway Server "kleeV2" ==<br />
'''IP/Domain:''' 10.50.72.7<br />
<br />
'''Standort:''' Amsterdam / Niederlande<br />
<br />
'''Owner:''' [[Benutzer:Green]]<br />
<br />
<br />
'''Übersicht / Statistiken:''' [http://kleev2.gw.fff.community http://kleev2.gw.fff.community] (nur Freifunk intern)<br />
<br />
'''OLSR-Infos:''' [http://kleev2.gw.fff.community:8080/all http://kleev2.gw.fff.community:8080/all] (nur Freifunk intern)<br />
<br />
'''Admins:'''<br />
* [[Benutzer:Green]]<br />
<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via OpenVPN (Mullvad)<br />
* DNS (Freifunk Static Stub Konfiguration)<br />
* IPIP Tunnel zu anderen GWs (ro1, nue1, bbg, cdfue1, has2, fra1)<br />
* IPv4 Gateway (dhcp) für<br />
** Aux<br />
** Würzburg<br />
<br />
== Gateway Server "fff-gw-cd1" ==<br />
'''IP/Domain:''' fff-gw-cd1.fff.community<br />
<br />
'''Standort:''' Falkenstein - Hetzner<br />
<br />
'''Owner:''' [[Benutzer:ChristianD]]<br />
<br />
<br />
'''Admins:'''<br />
* [[Benutzer:ChristianD]]<br />
<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via OpenVPN (Mullvad)<br />
* GRE-Tunnel für OSLR zu anderen Gateways (kleeV2, fff-gw-m1, has2, ro1, fff-pi-cd1)<br />
* IPv4 Internetgateway (dhcp) für<br />
** Fürth 'fff-gw-cdfue1'<br />
** Ansbach 'fff-gw-cdan1'<br />
** NbgLand 'fff-gw-cdnbgland1'<br />
* Client in Nürnberg zur Routerfernwartung außerhalb der eigenen Hood 'fff-gw-cdnue1'<br />
* nbgland Internettraffic wird über fff-pi-cd1 ins Internet geroutet [http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/2016-January/002417.html Mehr Infos]<br />
* Owncloud Server (Testbetrieb URL folgt...)<br />
* webbasiertes Forum (Testbetrieb URL folgt...)<br />
<br />
'''Statistiken:'''<br />
* Statistiken: [http://fff-gw-cd1.fff.community/index.php http://fff-gw-cd1.fff.community/index.php]<br />
<br />
== Internet Exit Server "fff-pi-cd1" ==<br />
'''IP/Domain:''' folgt<br />
<br />
'''Standort:''' [http://raspberry-host.de/ Raspberry Host]<br />
<br />
'''Owner:''' [[Benutzer:ChristianD]]<br />
<br />
<br />
'''Admins:'''<br />
* [[Benutzer:ChristianD]]<br />
<br />
'''Funktion:'''<br />
* Internetexit über Mullvad<br />
<br />
'''Statistiken:'''<br />
* [http://37.228.135.203/vnstat/ vnstat]<br />
<br />
== Gateway Server "fff-wue1" ==<br />
''' IP/Domain:''' 10.50.72.6<br />
<br />
''' Standort:''' Falkenstein (Hetzner)<br />
<br />
'''Owner:''' [[Benutzer:mifritscher]]<br />
<br />
<br />
'''Admins:'''<br />
* [[Benutzer:mifritscher]]<br />
<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via OpenVPN (Mullvad, Niederlande)<br />
* GRE-Tunnel für OSLR zu anderen Gateways <br />
** fff-has (10.50.72.3)<br />
** fff-has2 (10.50.56.3)<br />
** fff-has3 (10.50.56.6; per IPv6) - derzeit deaktiviert<br />
* IPv4 Internetgateway (dhcp) für<br />
** Würzburg<br />
** Nürnberg<br />
** Nbg-Land<br />
<br />
'''Statistiken:'''<br />
* Allgemeine Statistik zum Server: [http://188.40.170.116/monitoring/i.html]<br />
* Auslastung und Traffic Statistik: [http://10.50.72.6/mrtg http://10.50.72.6/mrtg] (nur Freifunk intern) oder [http://188.40.170.116/mrtg http://188.40.170.116/mrtg]<br />
* OLSR-Infos: [http://10.50.72.6:8080/all http://10.50.72.6:8080/all] (nur Freifunk intern) oder [http://188.40.170.116:8080/all http://188.40.170.116:8080/all]<br />
<br />
''' Hinweise '''<br />
Der Server wurde nach [[Freifunk-Gateway_aufsetzen]] aufgesetzt, die Statistik-Seite nach [[Portal:Netz/Statistiken]] erstellt.<br />
<br />
== Gateway Server "FFF-GW-M1" ==<br />
<br />
''' IP/Domain:''' 10.50.40.10<br />
<br />
''' Standort:''' Deutschland (netcup)<br />
<br />
'''Owner:''' [[Benutzer:mayosemmel]]<br />
<br />
<br />
'''Admins:'''<br />
* [[Benutzer:mayosemmel]]<br />
<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via OpenVPN (Mullvad, Land wechselnd je nach Performance)<br />
* Gateway zum IC-VPN [https://wiki.freifunk.net/IC-VPN]<br />
* GRE-Tunnel für OSLR zu anderen Gateways <br />
* IPv4 Internetgateway (dhcp) für<br />
** Nürnberg<br />
<br />
'''Statistiken:'''<br />
* OLSR-Infos: [http://10.50.40.10:8080/all http://10.50.40.10:8080/all] (nur Freifunk intern)<br />
* Weitere Statistiken: [http://10.50.40.10 http://10.50.40.10] (nur Freifunk intern)<br />
<br />
== Gateway Server "fff-gw-yaga" ==<br />
''' IP/Domain:''' 10.50.40.7<br />
<br />
''' Standort:''' Düsseldorf<br />
<br />
'''Owner:''' [[Benutzer:yaga]]<br />
<br />
'''OLSR-Infos:''' [http://10.50.40.7:8080/all http://10.50.40.7:8080/all] (nur Freifunk intern)<br />
<br />
'''Admins:'''<br />
* [[Benutzer:yaga]]<br />
<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via OpenVPN (privateinternetaccess, Holland)<br />
* GRE-Tunnel für OLSR zu anderen Gateways <br />
** fff-wue1 (10.50.252.22 <-> 10.50.252.23)<br />
** ro1 (10.50.252.40 <-> 10.50.252.41)<br />
** nue1 (10.50.252.42 <-> 10.50.252.43)<br />
* IPv4 Internetgateway (dhcp) für<br />
** Nürnberg<br />
** Erlangen<br />
<br />
== Gateway Server "fff-bbg" ==<br />
'''IP/Domain:''' 78.46.181.112/bbg.meskalero.de<br />
<br />
'''Standort:''' Falkenstein - Hetzner<br />
<br />
'''Owner:''' [[Benutzer:meskal]]<br />
<br />
'''Admins:'''<br />
* [[Benutzer:meskal]]<br />
<br />
'''Funktion:'''<br />
* Internet Uplink via olsr-Layer3 meshing<br />
* GRE-Tunnel für OLSR zu anderen Gateways <br />
** fff-fra1<br />
** fff-ro1<br />
** fff-nue1<br />
** fff-wue1<br />
** fff-has2<br />
** fff-klee<br />
* IPv4 Internetgateway (dhcp) für<br />
** Nürnberg<br />
** aux<br />
'''Statistik'''<br />
** http://bbg.meskalero.de/CGP/host.php?h=bbg.meskalero.de<br />
<br />
== Gateway Server "fff-kwadro" ==<br />
'''IP/Domain:''' 78.46.210.151<br />
<br />
'''Standort:''' Hetzner<br />
<br />
'''Owner:''' [[Benutzer:Kwadronaut]]<br />
<br />
'''Admins:'''<br />
* [[Benutzer:Kwadronaut]]<br />
<br />
'''Funktion:'''<br />
* GRE-Tunnel für OLSR zu anderen Gateways <br />
** fff-staufen<br />
** fff-ro1<br />
** fff-nue1<br />
** fff-watzmann<br />
** fff-cd1<br />
** fff-m1<br />
* IPv4 Internetgateway (dhcp) für<br />
** Erlangen (geplant)<br />
'''Statistik'''<br />
** sollte ich mal bauen<br />
<br />
= Sonstige Server =<br />
<br />
== Netmon Server "fff-netmon1" ==<br />
'''IP/Domain:''' fff-netmon1.wavecloud.de<br />
<br />
'''Standort:''' Nürnberg<br />
<br />
'''Owner:''' wavecloud.de<br />
<br />
'''Admins'''<br />
* [[Benutzer:Magenbrot]]<br />
* [[Benutzer:RedDog]]<br />
* Meskal<br />
* mrtnmb<br />
<br />
'''Funktion:'''<br />
* Netmon<br />
* ntdp<br />
* Keyxchange (/var/www/keyserver/fff/)<br />
<br />
== Webserver "fff_wiki1" ==<br />
'''IP/Domain:''' odin.ovtec.it<br />
<br />
'''Standort:''' Nürnberg<br />
<br />
'''Owner:''' [[Benutzer:magenbrot]]<br />
<br />
'''Admins'''<br />
* [[Benutzer:magenbrot]]<br />
<br />
'''Funktion:'''<br />
* [https://wiki.freifunk-franken.de wiki.freifunk.franken.de]<br />
* [http://ftp.freifunk-franken.de ftp.freifunk-franken.de]<br />
<br />
== LibreMapFranken ==<br />
'''IP/Domain:''' 95.85.40.145<br />
<br />
'''Type:''' VM (1GB Ram, 20GB SSD Disk, Ubuntu 13.04 x64)<br />
<br />
'''Standort:''' [http://speedtest-ams2.digitalocean.com/ Amsterdam]<br />
<br />
'''Owner:''' [[Benutzer:delphiN]]<br />
<br />
'''Admins'''<br />
* [[Benutzer:delphiN]]<br />
* Roland Greim<br />
<br />
'''Funktion:'''<br />
* [http://libremap.freifunk-franken.de:5984/libremap-dev/_design/libremap-webui/index.html libremap.freifunk-franken.de]<br />
* [https://github.com/FreifunkFranken/community.franken.freifunk.net/blob/master/updateFromNetmon.sh regelmäßige Updates der community api]<br />
<br />
== fff-nue2.fff.community ==<br />
* Host-System für versch. VMs:<br />
** todo ..<br />
<br />
Siehe auch [[Server/fff-nue2]]<br />
<br />
[[Kategorie:Technik]]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Portal:Netz&diff=5743
Portal:Netz
2016-02-25T19:27:11Z
<p>Green: /* Hood Fürth */</p>
<hr />
<div>== Das Netz ==<br />
Eine Karte der aktiven Router gibt es [https://netmon.freifunk-franken.de/map.php hier].<br />
<br />
Eine Karte der Hoods ist [http://keyserver.freifunk-franken.de/fff/voronoimap.php hier] zu finden.<br />
<br />
Die [https://netmon.freifunk-franken.de/routerlist.php Liste der Router] kann dank Netmon immer live verfolgt werden. Infos über die Schreibweise (z.B. "/20") gibt es in der [http://de.wikipedia.org/wiki/CIDR Wikipedia].<br />
<br />
=== Gateway ===<br />
Erste Versuche einer sinnvollen Aufteilung von Gateways. Erweiterungen und Verbesserungen sind jederzeit erwünscht. [https://pad.freifunk.net/p/Gatewayaufteilung-Franken Zum Pad]<br />
<br />
== IP-Netz ==<br />
Mit der Netz-Umstellung vom 22.03.2014 haben wir nicht mehr länger ein großes [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_2_.E2.80.93_Sicherungsschicht_.28Data_Link_Layer.29 Layer-II-Netz], welches durch das [https://de.wikipedia.org/wiki/B.A.T.M.A.N. B.A.T.M.A.N. advanced]-Protokoll geroutet wird. Seitdem gibt es mehrere [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_3_.E2.80.93_Vermittlungsschicht_.28Network_Layer.29 Layer-III-Netze] (Hoods). Ein Layer-III-Netz entsteht grundsätzlich, indem hier ein Subnetz eingetragen wird. Wie dabei genau vorgegangen wird, steht in [[HoodVerwaltung]].<br />
Für jedes Subnetz muss separat abgewogen werden, wie groß es werden wird und wo es dann in die bestehenden Subnetze am besten eingegliedert werden kann.<br />
<br />
==== DHCP ====<br />
[[Datei:Hoods.png|200px|thumb|right|Vorschlag für die Hood-Organisation]]<br />
Damit simple Clients das neue Subnetz nutzen können, muss ein eigener DHCP-Server pro Subnetz bereit gestellt werden. Es macht dabei häufig Sinn, das Subnetz in IP-Bereiche aufzuteilen, die von mehreren DHCP-Servern verteilt werden. Ein zweiter DHCP-Server ermöglicht zum einen eine Lastverteilung, zum anderen erhöht sich die Ausfallsicherheit. Der DHCP-Server muss den Clients ein Default-Gateway und mindestens einen DNS-Server zuweisen. Da das Default-Gateway ebenfalls innerhalb des Subnetzes liegen muss, bietet es sich an, den selben Server, auf dem das DHCP läuft, zu nutzen.<br />
<br />
==== OLSR-Router ====<br />
Das Subnetz muss anschließend an das vorhandene Freifunknetz angeschlossen werden. Dazu muss eine Verbindung zu einem bestehenden OLSR-Router aufgebaut werden. Dies kann eine VPN-Verbindung, aber auch eine Wifi-Verbindung sein und muss individuell zwischen den zwei Parteien ausgehandelt werden. Es kann sinnvoll sein, Verbindungen zu mehr als einem OLSR-Router zu haben. Sobald der eigene Router an das OLSR-Netz angebunden ist, ist er selbst ein OLSR-Router.<br />
<br />
An den eigenen OLSR-Router können nun Accesspoints angeschlossen werden. Dies kann per VPN, WLAN, Kabel oder anderweitig geschehen. Es ist auch möglich, den Accesspoint selbst als OLSR-Router anzubinden. Auch diese Konfiguration ist individuell zu klären. Ein Accesspoint kann ein (oder mehrere) einfacher Wifi-AP oder auch ein Array von mehreren B.A.T.M.A.N.-Knoten sein. Es sollte vermieden werden, dass sich Subnetze vermischen. Dies würde immer dann passieren, wenn zwei Layer-II-Netze, die eigentlich unterschiedliche Subnetze verteilen, verbunden werden. Besonders beim B.A.T.M.A.N.-Protokoll besteht hier leicht diese Gefahr; daher sollte für jedes Subnetz eine eigene BSSID und ESSID gewählt werden.<br />
<br />
==== Aus Routersicht ====<br />
Nur Router in einer Hood können sich per B.A.T.M.A.N. advanced vermaschen, sowohl per VPN, also auch per WLAN. Daher müssen Router die räumlich nahe beieinander stehen auch in derselben Hood sein. Durch das Vermaschen des Netzes wird allerdings auch Verwaltungs-Verkehr erzeugt (Overhead). Je größer die Hood, desto größer der Overhead.<br />
<br />
Eine Verbindung zwischen Routern in unterschiedlichen Hoods ist per IP (OSI Schicht 3) möglich.<br />
<br />
Wenn im Netmon kein Standort eingegeben wurde, dann landet der Router in der Dafault-Hood.<br />
<br />
==== Monitoring (Netmon) ====<br />
Aktuell können sich Knoten nur über ein IPv6-Link-Local-Interface beim Netmon anmelden und Netmon kann die Knoten nur über eine IPv6-Link-Local-Adresse abfragen. Hier muss ein neuer Mechanismus gefunden werden, der es ermöglicht, die Knoten über Subnetze hinweg anzusprechen.<br />
<br />
Als Workaround ist es möglich, über einen Layer-II-Tunnel zum Netmon-Server das Subnetz an das Netmon anzubinden. Auf dem Netmon-Server werden alle Subnetze in einem Bridge-Interface zusammengefasst, welches keine Pakete weiterleiten kann.<br />
<br />
==== Wireless-LAN ====<br />
Wir haben uns auf folgende WLAN-Parameter verständigt:<br />
'''ESSID: franken.freifunk.net'''. Kanal 1.<br />
<br />
== Liste der Subnetze ==<br />
{|<br />
! !! Bereich !! Bereitgestellt durch<br />
|-<br />
! 10.50.0.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.0.1 – 10.50.15.254</font> || <br />
|-<br />
! 10.50.16.0/20 || Default Hood ||<br />
|-<br />
| || 10.50.16.1 – 10.50.17.255 || Statische Adressen<br />
|-<br />
| || 10.50.18.0 – 10.50.19.255 || --<br />
|-<br />
| || 10.50.20.0 – 10.50.21.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey">10.50.22.0 – 10.50.23.254 </font> || <br />
|-<br />
| || <font color="grey">10.50.24.0 – 10.50.31.254 </font> || <br />
|-<br />
! 10.50.32.0/21 || Fürth Hood ||<br />
|-<br />
| || 10.50.32.1 – 10.50.32.255 || Statische Adressen<br />
|-<br />
| || <font color="grey"> 10.50.33.0 – 10.50.34.255 </font> || --<br />
|-<br />
| || 10.50.35.0 – 10.50.36.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey"> 10.50.37.0 – 10.50.37.255 </font> || --<br />
|-<br />
| || 10.50.38.0 – 10.50.39.254 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.40.0/21 || Nürnberg Hood ||<br />
|-<br />
| || 10.50.40.1 – 10.50.40.255 || Statische Adressen<br />
|-<br />
| || 10.50.41.0 – 10.50.42.255 || [[Server#FFF-GW-M1|FFF-GW-M1]]<br />
|-<br />
| || <font color="grey"> 10.50.43.0 - 10.50.43.255 </font> || <br />
|-<br />
| || 10.50.44.0 – 10.50.44.255 || (umgezogen) [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| ||10.50.45.0 – 10.50.46.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.47.0 – 10.50.47.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.48.0/21 || Ansbach Hood ||<br />
|-<br />
| || 10.50.48.1 – 10.50.48.255 || Statische Adressen<br />
|-<br />
| || 10.50.49.0 – 10.50.50.255 || <br />
|-<br />
| || 10.50.51.0 – 10.50.52.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.53.0 – 10.50.54.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| || <font color="grey">10.50.55.0 – 10.50.55.254</font> || <br />
|-<br />
! 10.50.56.0/22 || Hassberge Hood ||<br />
|-<br />
| || 10.50.56.1 – 10.50.56.255 || Statische Adressen<br />
|-<br />
| || 10.50.57.0 – 10.50.57.255 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
| || 10.50.58.0 – 10.50.58.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.59.0 – 10.50.59.244 || [[Server#fff-has|fff-has]]<br />
|-<br />
| || 10.50.59.245 – 10.50.59.254 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
! 10.50.60.0/22 || HassbergeSued Hood ||<br />
|-<br />
| || 10.50.60.1 – 10.50.60.255 || Statische Adressen<br />
|-<br />
| || 10.50.61.0 – 10.50.61.245 || [[Server#fff-has|fff-has]]<br />
|-<br />
| || 10.50.61.246 – 10.50.61.255 || [[Server#fff-has1|fff-has1]]<br />
|-<br />
| || 10.50.62.0 – 10.50.62.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.63.0 – 10.50.63.254 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
! 10.50.64.0/21 || Erlangen Hood ||<br />
|-<br />
| || 10.50.64.1 – 10.50.64.255 || Statische Adressen<br />
|-<br />
| || 10.50.65.0 – 10.50.66.255 || [[Server#fff-gw-kwadro|fff-gw-kwadro]]<br />
|-<br />
| || 10.50.67.0 – 10.50.68.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.69.0 – 10.50.71.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.72.0/21 || Würzburg Hood ||<br />
|-<br />
| || 10.50.72.1 – 10.50.72.255 || Statische Adressen<br />
|-<br />
| || <font color="grey"> 10.50.73.0 – 10.50.74.255 </font>|| <br />
|-<br />
| || 10.50.75.0 – 10.50.76.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.77.0 – 10.50.77.255 || [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || <font color="grey"> 10.50.78.0 – 10.50.78.255 </font>|| <br />
|-<br />
| || 10.50.79.0 – 10.50.79.254 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
! 10.50.80.0/21 || BGL ||<br />
|-<br />
| || 10.50.80.1 – 10.50.80.255 || Statische Adressen<br />
|-<br />
| || 10.50.81.0 – 10.50.82.255 || [[Server#watzmann|watzmann]]<br />
|-<br />
| || 10.50.83.0 – 10.50.84.255 || [[Server#staufen|staufen]]<br />
|-<br />
! 10.50.88.0/21 || NbgLand Hood ||<br />
|-<br />
| || 10.50.88.1 – 10.50.88.255 || Statische Adressen<br />
|-<br />
| || 10.50.89.0 – 10.50.89.255 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| || <font color="grey">10.50.90.0 - 10.50.93.255</font> || <br />
|-<br />
| || 10.50.94.0 – 10.50.95.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.96.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.96.1 – 10.50.127.254</font> || <br />
|-<br />
! 10.50.128.0/24 || Test von Casandro ||<br />
|-<br />
| || 10.50.128.20 – 10.50.128.200 || 10.50.128.1<br />
|-<br />
! 10.50.129.0/24 || Testtransfernet Olsr ChristianD ||<br />
|-<br />
| || 10.50.129.1 || Server fff-gw-cd1<br />
|-<br />
| || 10.50.129.2 || Hood Unterfürberg ChristianD Router 1<br />
|-<br />
! 10.50.130.0/24 || Konzept Unterfürberg ||<br />
|-<br />
| || <font color="black">10.50.130.0 – 10.50.130.255</font> || Testbereich ChristianD für [https://wiki.freifunk-franken.de/w/Standorte/Fuerth/Unterfuerberg/L3Konzept Konzept Unterfürberg]<br />
|-<br />
! 10.50.131.0/29 || fff-nue2 TEST TEST || <br />
|-<br />
| || 10.50.131.0 – 10.50.131.7 || [[Benutzer:RedDog|RedDog]] <br />
|-<br />
! 10.50.132.0/22 || border:none gateway ||<br />
|-<br />
| || 10.50.132.1 – 10.50.132.255 || Statische Adressen<br />
|-<br />
| || 10.50.133.0 – 10.50.134.255 || DHCP<br />
|-<br />
| || <font color="grey">10.50.135.0 – 10.50.135.254</font> || frei<br />
|-<br />
! 10.50.136.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.136.1 – 10.50.143.254</font> || <br />
|-<br />
! 10.50.144.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.144.1 – 10.50.159.254</font> || <br />
|-<br />
! 10.50.160.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.160.1 – 10.50.191.254</font> || <br />
|-<br />
! 10.50.192.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.192.1 – 10.50.223.254</font> || <br />
|-<br />
! 10.50.224.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.224.1 – 10.50.239.254</font> || <br />
|-<br />
! 10.50.240.0/20 ||Aufgeteilt: || <br />
|-<br />
! 10.50.240.0/21 || fffaux ||<br />
|-<br />
| || 10.50.240.1 – 10.50.240.255 || Statische Adressen<br />
|-<br />
| || 10.50.241.0 – 10.50.241.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.242.0 – 10.50.243.255 || [[Server#fff-fra1|fff-fra1]]<br />
|-<br />
| || 10.50.244.0 – 10.50.244.127 || Testinstallation Busch (Flo)<br />
|-<br />
| || 10.50.244.128 - 10.50.245.255 || | [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || <font color="grey">10.50.246.0 - 10.50.247.254</font> || <br />
|-<br />
<br />
! 10.50.248.0/22 || free ||<br />
|-<br />
| || 10.50.248.1 – 10.50.248.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.249.0 - 10.50.251.254</font> || <br />
|-<br />
! 10.50.252.0/22 || TUNNEL ||<br />
|-<br />
| || 10.50.252.0 fff_ro1 || 10.50.252.1 nue1 || <br />
|-<br />
| || 10.50.252.2 fff_ro1 || 10.50.252.3 watzmann || <br />
|-<br />
| || 10.50.252.4 fff_ro1 || 10.50.252.5 staufen || <br />
|-<br />
| || 10.50.252.6 fff_ro1 || 10.50.252.7 has2 || <br />
|-<br />
| || 10.50.252.8 fff_ro1 || 10.50.252.9 has || <br />
|-<br />
| || 10.50.252.10 ro1 || 10.50.252.11 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.12 fff-has2 || 10.50.252.13 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.14 fff-gw-m1 || 10.50.252.15 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.16 KleeV2 || 10.50.252.17 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.18 KleeV2 || 10.50.252.19 nue1 ||<br />
|-<br />
| || 10.50.252.20 KleeV2 || 10.50.252.21 ro1 ||<br />
|-<br />
| || 10.50.252.22 fff-gw-yaga || 10.50.252.23 fff-wue1 ||<br />
|-<br />
| || 10.50.252.24 fff-gw-m1 || 10.50.252.25 fff-has2 ||<br />
|-<br />
| || 10.50.252.26 fff-gw-m1 || 10.50.252.27 fff-wue1 ||<br />
|-<br />
| || 10.50.252.28 fff-bbg || 10.50.252.29 fff-nue1 ||<br />
|-<br />
| || 10.50.252.30 fff-bbg || 10.50.252.31 fff-ro1 ||<br />
|-<br />
| || 10.50.252.32 fff-bbg || 10.50.252.33 fff-has2 ||<br />
|-<br />
| || 10.50.252.34 fff-bbg || 10.50.252.35 KleeV2 ||<br />
|-<br />
| || 10.50.252.36 fff-wue1 || 10.50.252.37 fff-bbg ||<br />
|-<br />
| || 10.50.252.38 fff-gw-m1 || 10.50.252.39 ro1 ||<br />
|-<br />
| || 10.50.252.40 fff-gw-yaga || 10.50.252.41 ro1 ||<br />
|-<br />
| || 10.50.252.42 fff-gw-yaga || 10.50.252.43 nue1 ||<br />
|-<br />
| || 10.50.252.44 fff-roffl || 10.50.252.45 fff-has2 ||<br />
|-<br />
| || 10.50.252.46 fff-fra1 || 10.50.252.47 fff-bbg ||<br />
|-<br />
| || 10.50.252.48 fff-fra1 || 10.50.252.49 kleeV2 ||<br />
|-<br />
| || 10.50.252.50 fff-roffl || 10.50.252.51 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.52 fff-has2 || 10.50.252.53 kleeV2 ||<br />
|-<br />
| || 10.50.252.54 fff-has2 || 10.50.252.55 fff-fra1 ||<br />
|-<br />
| || 10.50.252.56 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.57 kwadronaut ||<br />
|-<br />
| || 10.50.252.58 fff-gw-m1 || 10.50.252.59 kwadronaut ||<br />
|-<br />
| || 10.50.252.60 fff-nue1 || 10.50.252.61 kwadronaut ||<br />
|-<br />
| || 10.50.252.62 ro1 || 10.50.252.63 kwadronaut ||<br />
|-<br />
| || 10.50.252.64 staufen || 10.50.252.65 kwadronaut ||<br />
|-<br />
| || 10.50.252.66 watzmann || 10.50.252.67 kwadronaut ||<br />
|-<br />
| || 10.50.252.68 kwadronaut || 10.50.252.69 yaga ||<br />
|-<br />
| || 10.50.252.250 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.251 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.252 Testsystem von [[Benutzer:ChristianD]] || 10.50.252.253 Testsystem2 von [[Benutzer:ChristianD]] ||<br />
|-<br />
! 10.83.0.0/16 || free for tests ||<br />
|-<br />
| || <font color="grey">10.83.0.1 - 10.83.255.254</font> || <br />
|-<br />
|}<br />
<br />
== Statische IP-Adressen ==<br />
Dienste müssen Ihre IP-Adressen natürlich aus dem Subnetz beziehen, in welchem sie angeschlossen sind. Damit es keine Konflikte gibt, muss die IP-Adresse hier registriert werden.<br />
<br />
=== Default Hood ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.16.0 – 10.50.17.255 || || IP-Bereich Default Hood || <br />
|-<br />
| 10.50.16.2 || fff-nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.16.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.16.11 || c.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.21 || rns3.franken.ff || DNS PoC - Recursor #3 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.16.100 || netmon.freifunk-franken.de || || [[Server#si1|Details]]<br />
|-<br />
| 10.50.16.112 ||???.franken.ff || Raspberry Pi, Test owncloud, FTP || MartinS<br />
|-<br />
| 10.50.16.128 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.150 ||Diagnose ChristianD || Diagnose ChristianD || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.16.200 ||???.franken.ff || Fileserver || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.16.212 ||???.franken.ff || NAS, verschiedene Services || JomJom<br />
|-<br />
| 10.50.16.222 ||???.franken.ff || VM, mom. nur Test || pixelchrome<br />
|-<br />
| 10.50.17.17 ||???.franken.ff || Teamspeak, sFTP, owncloud im Test || Johnny<br />
|-<br />
| 10.50.17.112 ||???.franken.ff || Webserver, Tests || wolli112<br />
|}<br />
<br />
=== Hood Fürth ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.32.0 – 10.50.32.255 || || IP-Bereich Fürth Hood || <br />
|-<br />
| 10.50.32.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.32.3 || fff-uk1.freifunk-franken.de || || [[Server#fff-uk1|Details]]<br />
|-<br />
| 10.50.32.4 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|- <br />
| 10.50.32.5 || frei || || <br />
|-<br />
| 10.50.32.6 || frei || ||<br />
|- <br />
| <font color="grey"> 10.50.32.7 </font>||<font color="grey"> (frei) </font> || ||<br />
|-<br />
| 10.50.32.26 || Test-PI || Statische IP des RasPI für Testzwecke || [[Benutzer:Hobo|Hobo]] <br />
|-<br />
| 10.50.32.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.32.70 || testbridgeap.bridge.fff.community || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.71 || testbridgeclient.bridge.fff.community || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.100 || MicroNAS || anonymous FTP (10GB) || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.101 || Wetterstation || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Daten bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.102 || Wetterkamera || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Bilder bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.109 || Raspi || Raspi Server im Höffner || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.110 || - || - || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.111 || stmichael.bridge.ws13.fff.community || Nanobeam M5 Bridge als AP auf St. Michael Richtung DelphiN || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.112 || ws13.bridge.stmichael.fff.community || Nanobeam M5 Bridge als Client bei DelphiN. Richtung St. Michael || [[Benutzer:delphiN|delphiN]], [[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.113 || || Bridge als AP auf St. Michael. Richtung Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.114 || || Bridge als Client bei Hoeffner. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.117 || || ToughSwitch Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.118 || || ToughSwitch auf WS13 || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.119 || || ToughSwitch auf StMichael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.120 || || ToughSwitch im Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.121 || || Bridge als AP auf St. Michael. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.122 || || Bridge als Client in Europaallee. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.123 || || Reserviert: Bridge als AP auf Hardhöhe. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.124 || || Bridge als Client in Europaallee. Richtung Hardhöhe || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.150 || ChristianD's PC || FFF-Netz ohne Internet || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.151 || feste Laptop IP || Für Speedtests mit manuellen Gateway || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.152 || RasPi || Testsystem || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.170 || HoeffnerPrinter || Drucker Computerraum Höffner || [[Benutzer:delphiN|delphiN]] <br />
|}<br />
<br />
=== Hood Nürnberg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.40.0 – 10.50.40.255 || || IP-Bereich Nürnberg Hood || <br />
|-<br />
| <strike>10.50.40.2</strike> || <strike>nue1.freifunk-franken.de</strike> || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.40.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.40.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.40.7 || fff-gw-yaga|| || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.40.8 || fff-bbg|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.10 || FFF-GW-M1 || || [[Server#FFF-GW-M1|Details]]<br />
|-<br />
| 10.50.40.11 || a.ns.franken.ff || DNS PoC - Master || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.12 || b.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.20 || - – - || Direct Connect HUB || [[Benutzer:TheFroggy|TheFroggy]]<br />
|-<br />
| 10.50.40.21 || rns1.franken.ff || DNS PoC - Recursor #1 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.22 || rns2.franken.ff || DNS PoC - Recursor #2 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| <strike>10.50.40.40</strike> || <strike>fff-synology.freifunk-franken.de</strike> || Umgezogen nach NBGLand || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.40.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.40.51 || mayo-test.fff.community || || [[Benutzer:mayosemmel|mayosemmel]]<br />
|-<br />
| 10.50.40.66 || flightradar.freifunk-franken.de || Dump1090 || [[Benutzer:Sixkiller6kl|sixkiller6kl]]<br />
|-<br />
| 10.50.40.98 || jabber.pm-ib.de || Jabber-Server || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.101 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.102 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.103 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.110 || ff_br_Spenglerstr || 5-GHz-Bridge Spenglerstr --> Johannis || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.111 || ff_Johannis || 5-GHz-Bridge Johannis --> Spenglerstr || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.120 || -- || 5-GHz-Access Point (Schniegling) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.121 || -- || 5-GHz-Client (Naturfreundehaus Nürnberg Mitte) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.130 || ff_nhgbr_Johnny || 5-GHz-Master (Standort Spenglerstr) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.131 || ff_nhgbr_NHG || 5-GHz-Slave (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.132 || ff_NHG_Osten || 5-GHz-Master (Standort Nachbarschaftshaus Goho, Richtung Osten) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.135 || ff_nhgswitch_NHG || POE-Switch (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.140 || ff_TS_PoE_tmp || 5-Port POE-Switch (für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.141 || ff_NS_M5_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.142 || ff_NS_M5_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.143 || ff_PB_5AC_500_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.144 || ff_PB_5AC_500_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.145 || ff_nhgbrsüd_M5loco_Master || 5-GHz-Master (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.146 || ff_Bauerngassebr_M5loco_Slave || 5-GHz-Slave (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.200 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Client, Routerfernwartung || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.201 – 10.50.40.205|| Test || bitte vorläufig freihalten, danke || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.230 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.231 ||???.franken.ff || Juniper SRX (VRF) || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.232 ||???.franken.ff || Raspberry Pi || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.233 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.234 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
| 10.50.43.165 || fffsvr01.franken.freifunk.net || SMB, FTP Server 250GB || [[Benutzer:ManuelS|ManuelS]]<br />
|}<br />
<br />
=== Hood Ansbach ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.48.0 – 10.50.48.255 || || IP-Bereich Ansbach Hood || <br />
|-<br />
| 10.50.48.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.48.3 || fff-gw-cdfue1 || || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| 10.50.48.20 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.21 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.48.230 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.231 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.232 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.233 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.234 || || mom. nur Test || JuzeCr<br />
|}<br />
<br />
=== Hood Hassberge ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.56.0 – 10.50.56.255 || || IP-Bereich Hassberge Hood || <br />
|-<br />
| 10.50.56.1 || fff-has1|| || [[Server#fff-has1|Details]] <br />
|-<br />
| 10.50.56.2 || <strike> nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]] </strike><br />
|-<br />
| 10.50.56.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.56.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.56.7 || fff-roffl|| || [[Server#fff-roffl|Details]]<br />
|-<br />
| 10.50.56.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| Bitte den Bereich 10.50.56.120 – 10.50.56.129 für [[Benutzer:Plocker|Plocker]] frei lassen<br />
|-<br />
| 10.50.56.123 || Teeworlds-Game-Server || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.124 || OwnCloud + Wiki || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.125 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.126 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.132 ||<strike> Webserver + MUD? || || [[Benutzer:PeterPhilipp|area52]]</strike><br />
|}<br />
<br />
=== Hood Hassberge Süd ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.60.0 – 10.50.60.255 || || IP-Bereich HassbergeSued Hood ||<br />
|-<br />
| 10.50.60.1 || fff-has1|| || [[Server#fff-has1|Details]] <br />
|-<br />
| 10.50.60.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.60.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.60.7 || fff-roffl|| || [[Server#fff-roffl|Details]] <br />
|-<br />
| 10.50.60.10 || Webcam Meehäusle Parkplatz|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.11 || Webcam Meehäusle Biergarten|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.100 /mediawiki || Webserver Mediawiki (in progress: Wikipedia(de)offline mirror)|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.101 /wiki || Raspi Webserver mit MediaWiki (Haßberge Wiki)|| || [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Erlangen ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.64.0 – 10.50.64.255 || || IP-Bereich Erlangen Hood || <br />
|-<br />
| 10.50.64.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.64.3 || fff-gw-yaga || || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.64.4 || fff-gw-kwadro || || [[Server#fff-gw-kwadro|Details]]<br />
|-<br />
| 10.50.64.10 || radiator.franken.ff || || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.11 || voip-1.radiator.franken.ff || Outernet, VoIP mittels SIP || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.12 || cam-1.radiator.franken.ff || IP-Cam || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.20 || radiatrix.franken.ff || geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.21 || cam-1.radiatrix.franken.ff || IP-Cam, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.22 || voip-1.radiatrix.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.30 || long.franken.ff || geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.31 || cam-1.long.franken.ff || IP-Cam, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.33 || voip-1.long.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.40 |||| Streaming Erlangen (im Aufbau) || [[Benutzer:R.funkt|R.funkt]]<br />
|-<br />
| 10.50.64.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.64.60 || gate3 || Dev || [[Benutzer:Jonas-bebe|Jonas-bebe]]<br />
|-<br />
| 10.50.64.70 |||| Raspi-Test || [[Benutzer:Dieter123|Dieter123]]<br />
<br />
|}<br />
<br />
=== Hood Würzburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.72.0 – 10.50.79.255 || || IP-Bereich Würzburg Hood || <br />
|-<br />
| 10.50.72.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.72.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.72.6 || fff-wue1|| || [[Server#fff-wue1|Details]] <br />
|-<br />
| 10.50.72.7 || kleeV2|| || [[Server#kleeV2|Details]] <br />
|-<br />
| 10.50.72.8 || 8PBSX1J || Netgear am FFF Netz || [[MisterCrumble|Details]] <br />
|-<br />
| 10.50.72.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.72.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood BGL ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.80.0 – 10.50.87.255 || || IP-Bereich BGL Hood || <br />
|-<br />
| 10.50.80.1 || watzmann || ||<br />
|-<br />
| 10.50.80.2 || staufen || ||<br />
|}<br />
<br />
=== Hood Nürnberger-Land ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.88.0 – 10.50.95.255 || || IP-Bereich NbgLand Hood || <br />
|-<br />
| 10.50.88.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.88.10 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.40 || fff-synology.freifunk-franken.de || Umzug nach Hood-Teilung || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.88.170 ||???.franken.ff || 5-GHz Richtfunk AP || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.171 ||???.franken.ff || 5-GHz Richtfunk Client || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.172 ||???.franken.ff || VM zum Testen || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood Aux ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
!10.50.240.1 – 10.50.247.254 || || IP-Bereich aux Hood || <br />
|-<br />
| 10.50.240.1 || fff-bbg || ||<br />
|-<br />
| 10.50.240.2 || fff-fra1 || ||<br />
|-<br />
| 10.50.240.7 || kleeV2 || ||<br />
|-<br />
| 10.50.240.20 || || Testgateway Flo für Hotel Busch |||<br />
|-<br />
| 10.50.240.11 || AP.bridge1.hoeffner.fff.community || Bridge AP Höffner || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.12 || S01.bridge1.hoeffner.fff.community || Bridge Station Hardhöhe || [[Benutzer:delphiN|delphiN]] ||<br />
|}</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Server/fff-fra1/Log&diff=5630
Server/fff-fra1/Log
2016-02-14T17:23:04Z
<p>Green: /* 03.12.2015 */</p>
<hr />
<div>__NOTOC__<br />
<br />
== 08.10.15 ==<br />
* Passwort für fffranken geändert.<br />
* Passwort für root geändert.<br />
<br />
== 09.10.15 ==<br />
=== sudo installieren (als root) ===<br />
<code><br />
apt-get update<br />
<br />
apt-get install sudo<br />
</code><br />
<br />
=== Neuen User delpiN angelegt (als root) ===<br />
<code><br />
adduser delphin<br />
<br />
adduser delphin sudo<br />
<br />
nano /etc/sudoers<br />
</code><br />
<pre><br />
# User privilege specification<br />
root ALL=(ALL:ALL) ALL<br />
delphin ALL=(ALL:ALL) ALL<br />
</pre><br />
<br />
=== fail2ban installiert und eingerichtet ===<br />
<code><br />
sudo apt-get install fail2ban<br />
<br />
sudo nano /etc/fail2ban/jail.local<br />
<br />
sudo /etc/init.d/fail2ban restart<br />
</code><br />
<br />
=== SSH Port geändert ===<br />
Es sollte einen Port gewählt werden der nicht bereits vergeben ist (Liste vergebener Ports: ''more /etc/services'')<br />
<br />
<code><br />
sudo nano /etc/ssh/sshd_config<br />
</code><br />
<pre><br />
# What ports, IPs and protocols we listen for<br />
Port 8024<br />
</pre><br />
<br />
<code><br />
/etc/init.d/ssh restart<br />
</code><br />
<br />
=== SSH Login nur über Key erlauben ===<br />
<code><br />
sudo nano /etc/ssh/sshd_config<br />
</code><br />
<pre><br />
RSAAuthentification no<br />
AuthorizedKeysFile %h/.ssh/authorized_keys<br />
IgnoreUserKnowHosts yes<br />
ChallengeResponseAuthentication no<br />
PasswordAuthentication no<br />
</pre><br />
<br />
<code><br />
sudo /etc/init.d/ssh restart<br />
</code><br />
<br />
=== vnstat installiert ===<br />
<code><br />
sudo apt-get install vnstat<br />
</code><br />
<br />
=== mtr installiert ===<br />
<code><br />
sudo apt-get install mtr<br />
</code><br />
<br />
== 11.10.15 ==<br />
* 3x User hinzugefügt (mifritscher, christiand, green) (login via ssh key only)<br />
* 3 Usern sudo Rechte eingeräumt (/etc/sudoers)<br />
* sudo ohne erneute Passwordeingabe (sudo visudo; username ALL=(ALL) NOPASSWD: ALL)<br />
* screen installiert<br />
* dist-upgrade<br />
* BTAMAN compilieren<br />
* batctl compiliert<br />
* fastd installiert<br />
* kein OpenVPN<br />
* DHCP<br />
* bind9<br />
* wget https://mifritscher.de/austausch/olsrd/jessie/olsrd_0.6.8.1-1_amd64.deb<br />
* wget https://mifritscher.de/austausch/olsrd/jessie/olsrd-plugins_0.6.8.1-1_amd64.deb<br />
* dpkg -i olsrd-plugins_0.6.8.1-1_amd64.deb<br />
* dpkg -i olsrd_0.6.8.1-1_amd64.deb<br />
<br />
* Packete auf FTP kopiert:<br />
** http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd-plugins_0.6.8.1-1_amd64.deb<br />
** http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd_0.6.8.1-1_amd64.deb<br />
<br />
<code><br />
# device: bat0<br />
iface bat0 inet manual<br />
post-up ifconfig $IFACE up<br />
##Einschalten post-up:<br />
# IP des Gateways am B.A.T.M.A.N interface:<br />
post-up ip addr add 10.50.240.2/21 dev $IFACE<br />
# Regeln, wann die fff Routing-Tabelle benutzt werden soll: <br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.0.0.0/8 table fff<br />
post-up ip rule add to 10.0.0.0/8 table fff<br />
# Route in die Aux Hood:<br />
post-up ip route add 10.50.240.0/21 dev $IFACE table fff<br />
# Start des DHCP Servers:<br />
### post-up invoke-rc.d isc-dhcp-server restart<br />
<br />
##Ausschalten post-down:<br />
# Loeschen von oben definieren Routen, Regeln und Interface: <br />
post-down ip route del 10.50.240.0/21 dev $IFACE table fff<br />
post-down ip rule del from 10.0.0.0/8 table fff<br />
post-down ip rule del to 10.0.0.0/8 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ifconfig $IFACE down<br />
<br />
# VPN Verbindung in die Aux Hood<br />
iface fffauxVPN inet manual<br />
post-up batctl -m bat0 if add $IFACE<br />
post-up ifconfig $IFACE up<br />
post-up ifup bat0<br />
post-down ifdown bat0<br />
post-down ifconfig $IFACE down<br />
</code><br />
* Fastd Skript einfügen<br />
<code><br />
christiand@fff-fra1:~$ cat /etc/fastd/fff_aux_fastd.sh<br />
#!/bin/sh<br />
<br />
SERVERNAME="fff-fra1"<br />
<br />
hood="def"<br />
project="fffaux"<br />
port=10000<br />
<br />
SERVERNAME="$SERVERNAME.$hood"<br />
<br />
hostname=$SERVERNAME<br />
<br />
if [ ! -d /etc/fastd ]<br />
then<br />
mkdir /etc/fastd<br />
fi<br />
<br />
if [ ! -d /etc/fastd/$project.$hood ]<br />
then<br />
mkdir /etc/fastd/$project.$hood<br />
mkdir /etc/fastd/$project.$hood/peers<br />
<br />
#fastd config<br />
(<br />
echo "# Log warnings and errors to stderr"<br />
echo "log level error;"<br />
echo "# Log everything to a log file"<br />
echo "log to syslog as \"${project}${hood}\" level info;"<br />
echo "# Set the interface name"<br />
echo "interface \"${project}${hood}VPN\";"<br />
echo "# Support xsalsa20 and aes128 encryption methods, prefer xsalsa20"<br />
echo "#method \"xsalsa20-poly1305\";"<br />
echo "#method \"aes128-gcm\";"<br />
echo "method \"null\";"<br />
echo "# Bind to a fixed port, IPv4 only"<br />
echo "bind any:${port};"<br />
echo "# Secret key generated by \"fastd --generate-key\""<br />
echo "secret \"$(fastd --generate-key | grep -i Secret | awk '{print $2}')\";"<br />
echo "# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)"<br />
echo "# (see MTU selection documentation)"<br />
echo "mtu 1426;"<br />
echo "on up \"/etc/fastd/${project}.${hood}/up.sh\";"<br />
echo "on post-down \"/etc/fastd/${project}.${hood}/down.sh\";"<br />
echo "# Include peers from the directory 'peers'"<br />
echo "include peers from \"/etc/fastd/${project}.${hood}/peers\";"<br />
echo "secure handshakes no;"<br />
) >> "/etc/fastd/$project.$hood/$project.$hood.conf"<br />
<br />
#fastd-up<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifdown \$INTERFACE"<br />
) >> /etc/fastd/$project.$hood/down.sh<br />
<br />
chmod +x /etc/fastd/$project.$hood/down.sh<br />
<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifup \$INTERFACE" >> /etc/fastd/$project.$hood/up.sh<br />
) >> /etc/fastd/$project.$hood/up.sh<br />
chmod +x /etc/fastd/$project.$hood/up.sh<br />
fi<br />
<br />
pubkey=$(fastd -c /etc/fastd/$project.$hood/$project.$hood.conf --show-key --machine-readable)<br />
port=$(grep ^bind /etc/fastd/$project.$hood/$project.$hood.conf | cut -d: -f2 | cut -d\; -f1)<br />
<br />
# fire up<br />
if [ "$(/sbin/ifconfig -a | grep -i ethernet | grep ${project}${hood}VPN)" = "" ]<br />
then<br />
/bin/rm /var/run/fastd.$project.$hood.pid<br />
fastd -c /etc/fastd/$project.$hood/$project.$hood.conf -d --pid-file /var/run/fastd.$project.$hood.pid<br />
fi<br />
<br />
# register<br />
wget -T15 -q "http://keyserver.freifunk-franken.de/${project}/?name=$hostname&port=$port&key=$pubkey" -O /tmp/fastd_${project}.${hood}_output<br />
if [ "$?" != "0" ]<br />
then<br />
echo "Update failed"<br />
echo "Exiting, no clean up, no refresh"<br />
exit<br />
fi<br />
<br />
touch /tmp/fastd_${project}.${hood}_starting<br />
<br />
filenames=$(cat /tmp/fastd_${project}.${hood}_output| grep ^#### | sed -e 's/^####//' | sed -e 's/.conf//g')<br />
for file in $filenames<br />
do<br />
grep -A100 ^####$file.conf$ /tmp/fastd_${project}.${hood}_output | grep -v ^####$file.conf$ | grep -m1 ^### -B100 | grep -v ^### | sed 's/ float;/;/g' > "/etc/fastd/$project.$hood/peers/$file"<br />
echo 'float yes;' >> "/etc/fastd/$project.$hood/peers/$file"<br />
done<br />
<br />
#find old peers<br />
OLD=$(find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print)<br />
<br />
if [ -n "${OLD}" ] ; then<br />
echo "Lösche alte:"<br />
echo $OLD<br />
<br />
find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print | xargs /bin/rm /tmp/fastd_${project}.${hood}_starting<br />
fi<br />
<br />
#reload<br />
kill -HUP "$(cat /var/run/fastd.$project.$hood.pid)"<br />
<br />
exit 0<br />
</code><br />
* Hostname geändert<br />
* IP Forwarding aktiviert<br />
* Fastd Skript ausführbar (chmod +x /etc/fastd/fff_aux_fastd.sh)<br />
* fastd Script gestartet, interface Name angepasst<br />
dabei gab es Probleme, erst beim 2. Start des fastd Scripts kamen die Interface richtig hoch.<br />
* fastd Script in crontab und rc.local<br />
* dns / bind9 als caching nameserver (8.8.8.8, 10.50.240.1)<br />
* batman gw selection 1:1 aus anleitung<br />
* bat0 als interface dhcp-server<br />
* dhcp config:<br />
<code><br />
## Freifunk Franken <br />
option domain-name "fff.community"; <br />
option domain-name-servers 10.50.240.2; <br />
authoritative; <br />
## aux <br />
subnet 10.50.32.0 netmask 255.255.248.0 { # Netzwerk und Netzmaske der Aux<br />
range 10.50.242.0 10.50.243.255; # IP-Range die der DHCP-Server i<br />
option routers 10.50.240.2; # Default-Gateway, dass Clients <br />
option domain-name-servers 10.50.240.2; # Name-Server, die Clients mitge<br />
}<br />
</code><br />
* gre Tunnel nach kleeV2 und bbg / klappt noch nicht / erneuter test nach einrichten von olsr<br />
<br />
* olsr installiert. interfaces nach kleeV2, bbg<br />
* tunnel nach kleev2 funktioniert<br />
* Routing Tabelle wird über kleev2 ausgetauscht<br />
* DHCP Subnetz nach 10.50.240.0/21 korrigiert<br />
* Probleme mit dem KeyXchange -> Fix von Tim, fastd Neustart<br />
* Client bezieht keine IP, Batman zeigt keinen Hop zum mit aux-FW geflashten Router<br />
* WR841ND mit Beta der Aux-Firmware geflascht. Nach langer Fehlersuche funktioniert B.A.T.M.A.N auf Router und GW. Zugang auf Router schwierig -> Anschluss von Client port und WAN port an Heimrouter. Später: Selbstheilung ohne erkennbare Einwirkung.<br />
* DHCP manuell gestartet, aus irgendwelchen Gründen nicht bei automatisch bei reboot.<br />
* Masquerading auf dem GW aktiviert: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE. Eintrag in /etc/rc.local<br />
* Test: Umleiten des Traffic von kleev2 nach fra1, indem neue default route in kleev2 definiert wurde ("ip route add default via 10.50.252.48 table fff") -> Erfolgreich<br />
<br />
== 12.10.2015 ==<br />
* apache2 installiert<br />
* snpd und mrtg nach https://wiki.freifunk-franken.de/w/Portal:Netz/Statistiken eingerichtet. Abweichung: statt CPU.cfg system.mfg und kein eigener index.<br />
* apache2 index in /etc/apache2/sites-available/000-default.conf nach /var/www geändert.<br />
* robots.txt -> /var/www: No searchbot crawling<br />
* vnstat nach http://www.tecmint.com/vnstat-php-frontend-for-monitoring-network-bandwidth/ eingerichtet. Databases "vnstat -u -i INTERFACE" und php-Anzeige /var/www/vnstat/config.php für eth0, bat0, kleeV2, bbg, fffauxdefVPN<br />
* Kopie von dhcpd-pool und dhcp-statistics.sh nach /usr/local/bin, Eintrag von dhcp-statistics.sh in die crontab (alle 5 Minuten)<br />
* In Crontab -> Tägliches Löschen von /var/www/topology-*.dot Dateien, die älter als 2 Tage sind (find /var/www -name "topology-????-??-??-??-??-??.dot" -mtime +2 | xargs rm -f)<br />
* Installation von phplot entsprechend http://www.phplot.com/phplotdocs/install.html<br />
* Webseite mit Monitoring Tools und Impressum hinzugefügt<br />
* ''curl'' installiert<br />
<br />
== 13.10.2015 ==<br />
* sudo user "dpaufler" angelegt. Key eingetragen.<br />
* node.js installiert:<br />
<code><br />
apt-get install npm<br />
<br />
sudo npm cache clean -f<br />
<br />
sudo npm install -g n<br />
<br />
sudo n stable<br />
<br />
sudo npm install npm -g<br />
</code><br />
<br />
== 14.10.2015 ==<br />
* [http://www.olsr.org/?q=jsoninfo_plugin OLSR_JsonInfo_Plugin] aktiviert. (Beispiel: http://84.200.64.42:9090/interfaces)<br />
<br />
== 17.10.2015 ==<br />
* Logrotate angepasst: 3 Tage backlogs ist Standard (/etc/logrotate.conf)<br />
* DHCP Ausgabe deaktiviert. Auszug aus /etc/log/rsyslogd.conf:<br />
<pre><br />
# /etc/rsyslog.conf Configuration file for rsyslog.<br />
#<br />
# For more information see<br />
# /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html<br />
<br />
<br />
##############<br />
#### DHCP ####<br />
##############<br />
#:programname, isequal, "dhcpd" /var/log/dhcpd.log<br />
:programname, isequal, "dhcpd" /dev/null<br />
:programname, isequal, "dhcpd" ~<br />
.<br />
.<br />
.<br />
</pre><br />
* Logrotate angepasst: 1 Tag backlog für /var/log/dhcpd.log (/etc/logrotate.conf)<br />
* Um logrotate von /var/lib/dhcp/dhcpd.leases zu ermöglichen, 5-minütigen cron-job eingerichtet, der folgendes ausführt: "chown -R dhcpd:dhcpd /var/lib/dhcp" (siehe https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1186662)<br />
<br />
== 19.10.2015 ==<br />
* iperf installiert<br />
* Logging-Regeln angepasst:<br />
** Verwerfen aller Logs von dhcpd. dump /etc/rsyslogd.conf<br />
<pre><br />
# /etc/rsyslog.conf Configuration file for rsyslog.<br />
#<br />
# For more information see<br />
# /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html<br />
<br />
<br />
##############<br />
#### DHCP ####<br />
##############<br />
#:programname, isequal, "dhcpd" /var/log/dhcpd.log<br />
:programname, isequal, "dhcpd" /dev/null<br />
:programname, isequal, "dhcpd" ~<br />
<br />
<br />
#################<br />
#### MODULES ####<br />
#################<br />
<br />
$ModLoad imuxsock # provides support for local system logging<br />
$ModLoad imklog # provides kernel logging support<br />
#$ModLoad immark # provides --MARK-- message capability<br />
<br />
# provides UDP syslog reception<br />
#$ModLoad imudp<br />
#$UDPServerRun 514<br />
<br />
# provides TCP syslog reception<br />
#$ModLoad imtcp<br />
#$InputTCPServerRun 514<br />
<br />
<br />
###########################<br />
#### GLOBAL DIRECTIVES ####<br />
###########################<br />
<br />
#<br />
# Use traditional timestamp format.<br />
# To enable high precision timestamps, comment out the following line.<br />
#<br />
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat<br />
<br />
#<br />
# Set the default permissions for all log files.<br />
#<br />
$FileOwner root<br />
$FileGroup adm<br />
$FileCreateMode 0640<br />
$DirCreateMode 0755<br />
$Umask 0022<br />
<br />
#<br />
# Where to place spool and state files<br />
#<br />
$WorkDirectory /var/spool/rsyslog<br />
<br />
#<br />
# Include all config files in /etc/rsyslog.d/<br />
#<br />
$IncludeConfig /etc/rsyslog.d/*.conf<br />
<br />
<br />
###############<br />
#### RULES ####<br />
###############<br />
<br />
#<br />
# First some standard log files. Log by facility.<br />
#<br />
auth,authpriv.* /var/log/auth.log<br />
*.*;auth,authpriv.none -/var/log/syslog<br />
#cron.* /var/log/cron.log<br />
daemon.* -/var/log/daemon.log<br />
kern.* -/var/log/kern.log<br />
lpr.* -/var/log/lpr.log<br />
mail.* -/var/log/mail.log<br />
user.* -/var/log/user.log<br />
<br />
#<br />
# Logging for the mail system. Split it up so that<br />
# it is easy to write scripts to parse these files.<br />
#<br />
mail.info -/var/log/mail.info<br />
mail.warn -/var/log/mail.warn<br />
mail.err /var/log/mail.err<br />
<br />
#<br />
# Logging for INN news system.<br />
#<br />
news.crit /var/log/news/news.crit<br />
news.err /var/log/news/news.err<br />
news.notice -/var/log/news/news.notice<br />
<br />
#<br />
# Some "catch-all" log files.<br />
#<br />
*.=debug;\<br />
auth,authpriv.none;\<br />
news.none;mail.none -/var/log/debug<br />
*.=info;*.=notice;*.=warn;\<br />
auth,authpriv.none;\<br />
cron,daemon.none;\<br />
mail,news.none -/var/log/messages<br />
<br />
#<br />
# Emergencies are sent to everybody logged in.<br />
#<br />
*.emerg :omusrmsg:*<br />
<br />
#<br />
# I like to have messages displayed on the console, but only on a virtual<br />
# console I usually leave idle.<br />
#<br />
#daemon,mail.*;\<br />
# news.=crit;news.=err;news.=notice;\<br />
# *.=debug;*.=info;\<br />
# *.=notice;*.=warn /dev/tty8<br />
<br />
# The named pipe /dev/xconsole is for the `xconsole' utility. To use it,<br />
# you must invoke `xconsole' with the `-file' option:<br />
# <br />
# $ xconsole -file /dev/xconsole [...]<br />
#<br />
# NOTE: adjust the list below, or you'll go crazy if you have a reasonably<br />
# busy site..<br />
#<br />
daemon.*;mail.*;\<br />
news.err;\<br />
*.=debug;*.=info;\<br />
*.=notice;*.=warn |/dev/xconsole<br />
</pre><br />
** Generell 3 Tage backlogs:<br />
<pre><br />
# see "man logrotate" for details<br />
# rotate log files daily<br />
daily<br />
<br />
# keep 3 days worth of backlogs<br />
rotate 3<br />
<br />
# create new (empty) log files after rotating old ones<br />
create<br />
<br />
# uncomment this if you want your log files compressed<br />
compress<br />
<br />
# packages drop log rotation information into this directory<br />
include /etc/logrotate.d<br />
<br />
# no packages own wtmp, or btmp -- we'll rotate them here<br />
/var/log/wtmp {<br />
missingok<br />
monthly<br />
create 0664 root utmp<br />
rotate 1<br />
}<br />
<br />
/var/log/btmp {<br />
missingok<br />
monthly<br />
create 0660 root utmp<br />
rotate 1<br />
}<br />
<br />
# system-specific logs may be configured here<br />
<br />
# system-specific logs may be configured here<br />
/var/log/dhcpd.log {<br />
rotate 1<br />
daily<br />
compress<br />
}<br />
</pre><br />
** Flush des DHCP lease files um 3.31 Uhr morgens. Dump crontab:<br />
<pre><br />
# m h dom mon dow command<br />
*/10 * * * * sh /etc/fastd/fff_aux_fastd.sh<br />
*/5 * * * * perl /etc/olsrd/dotDraw.pl > /dev/null 2>&1<br />
*/1 * * * * env LANG=C /usr/bin/mrtg /etc/mrtg/system.cfg > /dev/null 2>&1<br />
*/1 * * * * env LANG=C /usr/bin/mrtg /etc/mrtg/traffic.cfg > /dev/null 2>&1<br />
*/5 * * * * /usr/bin/vnstat -u >/dev/null 2>&1<br />
*/5 * * * * sudo dhcp-statistics.sh<br />
45 2 * * * find /var/www/topology/. -name "topology-????-??-??-??-??-??.dot" -mtime +1 | xargs rm -f<br />
#*/5 * * * * sudo chown -R dhcpd:dhcpd /var/lib/dhcp<br />
31 3 * * * sudo flush_dhcp.sh<br />
</pre><br />
** Flush des DHCP lease files um 3.31 Uhr morgens. Dump flush_dhcp.sh:<br />
<pre><br />
#!/bin/bash<br />
leasefile="/var/lib/dhcp/dhcpd.leases"<br />
<br />
/etc/init.d/isc-dhcp-server stop<br />
rm "$leasefile"<br />
rm "$leasefile~"<br />
touch "$leasefile"<br />
echo "" > "$leasefile"<br />
/etc/init.d/isc-dhcp-server start<br />
</pre><br />
<br />
== 22.10.2015 ==<br />
* Umstellung des IP-Bereichs auf 84.200.64.40/29<br />
<br />
== 23.10.2015 ==<br />
* Christohper Mäuer (von dotmanaged) User angelegt<br />
* Eintrag in der /etc/rc.local eingefügt:<br />
<pre><br />
#dhcp-server starten - geht beim Systemstart nicht, da dann das entsprechende Interface noch nicht da ist<br />
(sleep 30; /etc/init.d/isc-dhcp-server start) &<br />
</pre><br />
<br />
<br />
== 31.10.2015 ==<br />
* Revision der Logging-Rules: Dedicated log-file für snmpd<br />
* Auszug rsyslogd.conf:<br />
<pre><br />
###############<br />
#### SNMPD ####<br />
###############<br />
# Redirect snmpd<br />
:programname, isequal, "snmpd" /var/log/snmpd.log<br />
:programname, isequal, "snmpd" ~<br />
</pre><br />
<br />
* Auszug logrotate.conf:<br />
<pre><br />
/var/log/snmpd.log {<br />
rotate 3<br />
daily<br />
compress<br />
}<br />
</pre><br />
<br />
* Revision der logging rules: 3 Tage backlog für apache2. Dump /etc/logrotate.d/apache2:<br />
<pre><br />
/var/log/apache2/*.log {<br />
daily<br />
missingok<br />
rotate 3<br />
compress<br />
delaycompress<br />
notifempty<br />
create 640 root adm<br />
sharedscripts<br />
postrotate<br />
if /etc/init.d/apache2 status > /dev/null ; then \<br />
/etc/init.d/apache2 reload > /dev/null; \<br />
fi;<br />
endscript<br />
prerotate<br />
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \<br />
run-parts /etc/logrotate.d/httpd-prerotate; \<br />
fi; \<br />
endscript<br />
}<br />
</pre><br />
<br />
* Revision der logging rules: 3 Tage backlog für /var/log/syslog. Dump /etc/logrotate.d/rsyslog:<br />
<pre><br />
/var/log/syslog<br />
{<br />
rotate 3<br />
daily<br />
missingok<br />
notifempty<br />
delaycompress<br />
compress<br />
postrotate<br />
invoke-rc.d rsyslog rotate > /dev/null<br />
endscript<br />
}<br />
<br />
/var/log/mail.info<br />
/var/log/mail.warn<br />
/var/log/mail.err<br />
/var/log/mail.log<br />
/var/log/daemon.log<br />
/var/log/kern.log<br />
/var/log/auth.log<br />
/var/log/user.log<br />
/var/log/lpr.log<br />
/var/log/cron.log<br />
/var/log/debug<br />
/var/log/messages<br />
{<br />
rotate 4<br />
weekly<br />
missingok<br />
notifempty<br />
compress<br />
delaycompress<br />
sharedscripts<br />
postrotate<br />
invoke-rc.d rsyslog rotate > /dev/null<br />
endscript<br />
}<br />
</pre><br />
<br />
== 03.12.2015 ==<br />
* mrtg max range für fffauxvpn und bat0 angepasst<br />
* gre tunnel nach has2 hinzugefügt<br />
<br />
== 14.02.2016 ==<br />
* Freifunk DNS Konfiguration entsprechend https://wiki.freifunk-franken.de/w/DNS#Beispielhafte_Installation eingerichtet.</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Portal:Netz&diff=5568
Portal:Netz
2016-02-07T08:20:36Z
<p>Green: /* Hood Fürth */</p>
<hr />
<div>== Das Netz ==<br />
Eine Karte der aktiven Router gibt es [https://netmon.freifunk-franken.de/map.php hier].<br />
<br />
Eine Karte der Hoods ist [http://keyserver.freifunk-franken.de/fff/voronoimap.php hier] zu finden.<br />
<br />
Die [https://netmon.freifunk-franken.de/routerlist.php Liste der Router] kann dank Netmon immer live verfolgt werden. Infos über die Schreibweise (z.B. "/20") gibt es in der [http://de.wikipedia.org/wiki/CIDR Wikipedia].<br />
<br />
=== Gateway ===<br />
Erste Versuche einer sinnvollen Aufteilung von Gateways. Erweiterungen und Verbesserungen sind jederzeit erwünscht. [https://pad.freifunk.net/p/Gatewayaufteilung-Franken Zum Pad]<br />
<br />
== IP-Netz ==<br />
Mit der Netz-Umstellung vom 22.03.2014 haben wir nicht mehr länger ein großes [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_2_.E2.80.93_Sicherungsschicht_.28Data_Link_Layer.29 Layer-II-Netz], welches durch das [https://de.wikipedia.org/wiki/B.A.T.M.A.N. B.A.T.M.A.N. advanced]-Protokoll geroutet wird. Seitdem gibt es mehrere [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_3_.E2.80.93_Vermittlungsschicht_.28Network_Layer.29 Layer-III-Netze] (Hoods). Ein Layer-III-Netz entsteht grundsätzlich, indem hier ein Subnetz eingetragen wird. Wie dabei genau vorgegangen wird, steht in [[HoodVerwaltung]].<br />
Für jedes Subnetz muss separat abgewogen werden, wie groß es werden wird und wo es dann in die bestehenden Subnetze am besten eingegliedert werden kann.<br />
<br />
==== DHCP ====<br />
[[Datei:Hoods.png|200px|thumb|right|Vorschlag für die Hood-Organisation]]<br />
Damit simple Clients das neue Subnetz nutzen können, muss ein eigener DHCP-Server pro Subnetz bereit gestellt werden. Es macht dabei häufig Sinn, das Subnetz in IP-Bereiche aufzuteilen, die von mehreren DHCP-Servern verteilt werden. Ein zweiter DHCP-Server ermöglicht zum einen eine Lastverteilung, zum anderen erhöht sich die Ausfallsicherheit. Der DHCP-Server muss den Clients ein Default-Gateway und mindestens einen DNS-Server zuweisen. Da das Default-Gateway ebenfalls innerhalb des Subnetzes liegen muss, bietet es sich an, den selben Server, auf dem das DHCP läuft, zu nutzen.<br />
<br />
==== OLSR-Router ====<br />
Das Subnetz muss anschließend an das vorhandene Freifunknetz angeschlossen werden. Dazu muss eine Verbindung zu einem bestehenden OLSR-Router aufgebaut werden. Dies kann eine VPN-Verbindung, aber auch eine Wifi-Verbindung sein und muss individuell zwischen den zwei Parteien ausgehandelt werden. Es kann sinnvoll sein, Verbindungen zu mehr als einem OLSR-Router zu haben. Sobald der eigene Router an das OLSR-Netz angebunden ist, ist er selbst ein OLSR-Router.<br />
<br />
An den eigenen OLSR-Router können nun Accesspoints angeschlossen werden. Dies kann per VPN, WLAN, Kabel oder anderweitig geschehen. Es ist auch möglich, den Accesspoint selbst als OLSR-Router anzubinden. Auch diese Konfiguration ist individuell zu klären. Ein Accesspoint kann ein (oder mehrere) einfacher Wifi-AP oder auch ein Array von mehreren B.A.T.M.A.N.-Knoten sein. Es sollte vermieden werden, dass sich Subnetze vermischen. Dies würde immer dann passieren, wenn zwei Layer-II-Netze, die eigentlich unterschiedliche Subnetze verteilen, verbunden werden. Besonders beim B.A.T.M.A.N.-Protokoll besteht hier leicht diese Gefahr; daher sollte für jedes Subnetz eine eigene BSSID und ESSID gewählt werden.<br />
<br />
==== Aus Routersicht ====<br />
Nur Router in einer Hood können sich per B.A.T.M.A.N. advanced vermaschen, sowohl per VPN, also auch per WLAN. Daher müssen Router die räumlich nahe beieinander stehen auch in derselben Hood sein. Durch das Vermaschen des Netzes wird allerdings auch Verwaltungs-Verkehr erzeugt (Overhead). Je größer die Hood, desto größer der Overhead.<br />
<br />
Eine Verbindung zwischen Routern in unterschiedlichen Hoods ist per IP (OSI Schicht 3) möglich.<br />
<br />
Wenn im Netmon kein Standort eingegeben wurde, dann landet der Router in der Dafault-Hood.<br />
<br />
==== Monitoring (Netmon) ====<br />
Aktuell können sich Knoten nur über ein IPv6-Link-Local-Interface beim Netmon anmelden und Netmon kann die Knoten nur über eine IPv6-Link-Local-Adresse abfragen. Hier muss ein neuer Mechanismus gefunden werden, der es ermöglicht, die Knoten über Subnetze hinweg anzusprechen.<br />
<br />
Als Workaround ist es möglich, über einen Layer-II-Tunnel zum Netmon-Server das Subnetz an das Netmon anzubinden. Auf dem Netmon-Server werden alle Subnetze in einem Bridge-Interface zusammengefasst, welches keine Pakete weiterleiten kann.<br />
<br />
==== Wireless-LAN ====<br />
Wir haben uns auf folgende WLAN-Parameter verständigt:<br />
'''ESSID: franken.freifunk.net'''. Kanal 1.<br />
<br />
== Liste der Subnetze ==<br />
{|<br />
! !! Bereich !! Bereitgestellt durch<br />
|-<br />
! 10.50.0.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.0.1 – 10.50.15.254</font> || <br />
|-<br />
! 10.50.16.0/20 || Default Hood ||<br />
|-<br />
| || 10.50.16.1 – 10.50.17.255 || Statische Adressen<br />
|-<br />
| || 10.50.18.0 – 10.50.19.255 || --<br />
|-<br />
| || 10.50.20.0 – 10.50.21.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey">10.50.22.0 – 10.50.23.254 </font> || <br />
|-<br />
| || <font color="grey">10.50.24.0 – 10.50.31.254 </font> || <br />
|-<br />
! 10.50.32.0/21 || Fürth Hood ||<br />
|-<br />
| || 10.50.32.1 – 10.50.32.255 || Statische Adressen<br />
|-<br />
| || <font color="grey"> 10.50.33.0 – 10.50.34.255 </font> || --<br />
|-<br />
| || 10.50.35.0 – 10.50.36.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey"> 10.50.37.0 – 10.50.37.255 </font> || --<br />
|-<br />
| || 10.50.38.0 – 10.50.39.254 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.40.0/21 || Nürnberg Hood ||<br />
|-<br />
| || 10.50.40.1 – 10.50.40.255 || Statische Adressen<br />
|-<br />
| || 10.50.41.0 – 10.50.42.255 || [[Server#FFF-GW-M1|FFF-GW-M1]]<br />
|-<br />
| || <font color="grey"> 10.50.43.0 - 10.50.43.255 </font> || <br />
|-<br />
| || 10.50.44.0 – 10.50.44.255 || (umgezogen) [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| ||10.50.45.0 – 10.50.46.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.47.0 – 10.50.47.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.48.0/21 || Ansbach Hood ||<br />
|-<br />
| || 10.50.48.1 – 10.50.48.255 || Statische Adressen<br />
|-<br />
| || 10.50.49.0 – 10.50.50.255 || <br />
|-<br />
| || 10.50.51.0 – 10.50.52.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.53.0 – 10.50.54.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| || <font color="grey">10.50.55.0 – 10.50.55.254</font> || <br />
|-<br />
! 10.50.56.0/22 || Hassberge Hood ||<br />
|-<br />
| || 10.50.56.1 – 10.50.56.255 || Statische Adressen<br />
|-<br />
| || 10.50.57.0 – 10.50.57.255 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
| || 10.50.58.0 – 10.50.58.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.59.0 – 10.50.59.254 || [[Server#fff-has|fff-has]]<br />
|-<br />
! 10.50.60.0/22 || HassbergeSued Hood ||<br />
|-<br />
| || 10.50.60.1 – 10.50.60.255 || Statische Adressen<br />
|-<br />
| || 10.50.61.0 – 10.50.61.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
| || 10.50.62.0 – 10.50.62.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.63.0 – 10.50.63.254 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
! 10.50.64.0/21 || Erlangen Hood ||<br />
|-<br />
| || 10.50.64.1 – 10.50.64.255 || Statische Adressen<br />
|-<br />
| || 10.50.65.0 – 10.50.66.255 || [[Server#fff-gw-kwadro|fff-gw-kwadro]]<br />
|-<br />
| || 10.50.67.0 – 10.50.68.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.69.0 – 10.50.71.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.72.0/21 || Würzburg Hood ||<br />
|-<br />
| || 10.50.72.1 – 10.50.72.255 || Statische Adressen<br />
|-<br />
| || <font color="grey"> 10.50.73.0 – 10.50.74.255 </font>|| <br />
|-<br />
| || 10.50.75.0 – 10.50.76.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.77.0 – 10.50.77.255 || [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || <font color="grey"> 10.50.78.0 – 10.50.78.255 </font>|| <br />
|-<br />
| || 10.50.79.0 – 10.50.79.254 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
! 10.50.80.0/21 || BGL ||<br />
|-<br />
| || 10.50.80.1 – 10.50.80.255 || Statische Adressen<br />
|-<br />
| || 10.50.81.0 – 10.50.82.255 || [[Server#watzmann|watzmann]]<br />
|-<br />
| || 10.50.83.0 – 10.50.84.255 || [[Server#staufen|staufen]]<br />
|-<br />
! 10.50.88.0/21 || NbgLand Hood ||<br />
|-<br />
| || 10.50.88.1 – 10.50.88.255 || Statische Adressen<br />
|-<br />
| || 10.50.89.0 – 10.50.89.255 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| || <font color="grey">10.50.90.0 - 10.50.93.255</font> || <br />
|-<br />
| || 10.50.94.0 – 10.50.95.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.96.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.96.1 – 10.50.127.254</font> || <br />
|-<br />
! 10.50.128.0/24 || Test von Casandro ||<br />
|-<br />
| || 10.50.128.20 – 10.50.128.200 || 10.50.128.1<br />
|-<br />
! 10.50.129.0/24 || free ||<br />
|-<br />
| || || <br />
|-<br />
! 10.50.130.0/24 || free ||<br />
|-<br />
| || <font color="black">10.50.130.1 – 10.50.130.254</font> || Testbereich ChristianD für [https://wiki.freifunk-franken.de/w/Standorte/Fuerth/Unterfuerberg/L3Konzept Konzept Unterfürberg]<br />
|-<br />
! 10.50.131.0/24 || free ||<br />
|-<br />
| || <font color="grey">10.50.131.1 – 10.50.131.254</font> || <br />
|-<br />
! 10.50.132.0/22 || border:none gateway ||<br />
|-<br />
| || 10.50.132.1 – 10.50.132.255 || Statische Adressen<br />
|-<br />
| || 10.50.133.0 – 10.50.134.255 || DHCP<br />
|-<br />
| || <font color="grey">10.50.135.0 – 10.50.135.254</font> || frei<br />
|-<br />
! 10.50.136.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.136.1 – 10.50.143.254</font> || <br />
|-<br />
! 10.50.144.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.144.1 – 10.50.159.254</font> || <br />
|-<br />
! 10.50.160.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.160.1 – 10.50.191.254</font> || <br />
|-<br />
! 10.50.192.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.192.1 – 10.50.223.254</font> || <br />
|-<br />
! 10.50.224.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.224.1 – 10.50.239.254</font> || <br />
|-<br />
! 10.50.240.0/20 ||Aufgeteilt: || <br />
|-<br />
! 10.50.240.0/21 || fffaux ||<br />
|-<br />
| || 10.50.240.1 – 10.50.240.255 || Statische Adressen<br />
|-<br />
| || 10.50.241.0 – 10.50.241.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.242.0 – 10.50.243.255 || [[Server#fff-fra1|fff-fra1]]<br />
|-<br />
| || 10.50.244.0 – 10.50.244.127 || Testinstallation Busch (Flo)<br />
|-<br />
| || 10.50.244.128 - 10.50.245.255 || | [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || <font color="grey">10.50.246.0 - 10.50.247.254</font> || <br />
|-<br />
<br />
! 10.50.248.0/22 || free ||<br />
|-<br />
| || 10.50.248.1 – 10.50.248.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.249.0 - 10.50.251.254</font> || <br />
|-<br />
! 10.50.252.0/22 || TUNNEL ||<br />
|-<br />
| || 10.50.252.0 fff_ro1 || 10.50.252.1 nue1 || <br />
|-<br />
| || 10.50.252.2 fff_ro1 || 10.50.252.3 watzmann || <br />
|-<br />
| || 10.50.252.4 fff_ro1 || 10.50.252.5 staufen || <br />
|-<br />
| || 10.50.252.6 fff_ro1 || 10.50.252.7 has2 || <br />
|-<br />
| || 10.50.252.8 fff_ro1 || 10.50.252.9 has || <br />
|-<br />
| || 10.50.252.10 ro1 || 10.50.252.11 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.12 fff-has2 || 10.50.252.13 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.14 fff-gw-m1 || 10.50.252.15 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.16 KleeV2 || 10.50.252.17 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.18 KleeV2 || 10.50.252.19 nue1 ||<br />
|-<br />
| || 10.50.252.20 KleeV2 || 10.50.252.21 ro1 ||<br />
|-<br />
| || 10.50.252.22 fff-gw-yaga || 10.50.252.23 fff-wue1 ||<br />
|-<br />
| || 10.50.252.24 fff-gw-m1 || 10.50.252.25 fff-has2 ||<br />
|-<br />
| || 10.50.252.26 fff-gw-m1 || 10.50.252.27 fff-wue1 ||<br />
|-<br />
| || 10.50.252.28 fff-bbg || 10.50.252.29 fff-nue1 ||<br />
|-<br />
| || 10.50.252.30 fff-bbg || 10.50.252.31 fff-ro1 ||<br />
|-<br />
| || 10.50.252.32 fff-bbg || 10.50.252.33 fff-has2 ||<br />
|-<br />
| || 10.50.252.34 fff-bbg || 10.50.252.35 KleeV2 ||<br />
|-<br />
| || 10.50.252.36 fff-wue1 || 10.50.252.37 fff-bbg ||<br />
|-<br />
| || 10.50.252.38 fff-gw-m1 || 10.50.252.39 ro1 ||<br />
|-<br />
| || 10.50.252.40 fff-gw-yaga || 10.50.252.41 ro1 ||<br />
|-<br />
| || 10.50.252.42 fff-gw-yaga || 10.50.252.43 nue1 ||<br />
|-<br />
| || 10.50.252.44 fff-roffl || 10.50.252.45 fff-has2 ||<br />
|-<br />
| || 10.50.252.46 fff-fra1 || 10.50.252.47 fff-bbg ||<br />
|-<br />
| || 10.50.252.48 fff-fra1 || 10.50.252.49 kleeV2 ||<br />
|-<br />
| || 10.50.252.50 fff-roffl || 10.50.252.51 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.52 fff-has2 || 10.50.252.53 kleeV2 ||<br />
|-<br />
| || 10.50.252.54 fff-has2 || 10.50.252.55 fff-fra1 ||<br />
|-<br />
| || 10.50.252.56 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.57 kwadronaut ||<br />
|-<br />
| || 10.50.252.58 fff-gw-m1 || 10.50.252.59 kwadronaut ||<br />
|-<br />
| || 10.50.252.60 fff-nue1 || 10.50.252.61 kwadronaut ||<br />
|-<br />
| || 10.50.252.62 ro1 || 10.50.252.63 kwadronaut ||<br />
|-<br />
| || 10.50.252.64 staufen || 10.50.252.65 kwadronaut ||<br />
|-<br />
| || 10.50.252.66 watzmann || 10.50.252.67 kwadronaut ||<br />
|-<br />
| || 10.50.252.68 kwadronaut || 10.50.252.69 yaga ||<br />
|-<br />
| || 10.50.252.250 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.251 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.252 Testsystem von [[Benutzer:ChristianD]] || 10.50.252.253 Testsystem2 von [[Benutzer:ChristianD]] ||<br />
|-<br />
! 10.83.0.0/16 || free for tests ||<br />
|-<br />
| || <font color="grey">10.83.0.1 - 10.83.255.254</font> || <br />
|-<br />
|}<br />
<br />
== Statische IP-Adressen ==<br />
Dienste müssen Ihre IP-Adressen natürlich aus dem Subnetz beziehen, in welchem sie angeschlossen sind. Damit es keine Konflikte gibt, muss die IP-Adresse hier registriert werden.<br />
<br />
=== Default Hood ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.16.0 – 10.50.17.255 || || IP-Bereich Default Hood || <br />
|-<br />
| 10.50.16.2 || fff-nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.16.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.16.11 || c.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.21 || rns3.franken.ff || DNS PoC - Recursor #3 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.16.100 || netmon.freifunk-franken.de || || [[Server#si1|Details]]<br />
|-<br />
| 10.50.16.112 ||???.franken.ff || Raspberry Pi, Test owncloud, FTP || MartinS<br />
|-<br />
| 10.50.16.128 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.150 ||Diagnose ChristianD || Diagnose ChristianD || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.16.200 ||???.franken.ff || Fileserver || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.16.212 ||???.franken.ff || NAS, verschiedene Services || JomJom<br />
|-<br />
| 10.50.16.222 ||???.franken.ff || VM, mom. nur Test || pixelchrome<br />
|-<br />
| 10.50.17.17 ||???.franken.ff || Teamspeak, sFTP, owncloud im Test || Johnny<br />
|-<br />
| 10.50.17.112 ||???.franken.ff || Webserver, Tests || wolli112<br />
|}<br />
<br />
=== Hood Fürth ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.32.0 – 10.50.32.255 || || IP-Bereich Fürth Hood || <br />
|-<br />
| 10.50.32.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.32.3 || fff-uk1.freifunk-franken.de || || [[Server#fff-uk1|Details]]<br />
|-<br />
| 10.50.32.4 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|- <br />
| <font color="grey">10.50.32.5</font> || <font color="grey"> (frei) </font> || || <br />
|- <br />
| <font color="grey">10.50.32.6</font> || <font color="grey"> (frei) </font> || || <br />
|- <br />
| <font color="grey"> 10.50.32.7 </font>||<font color="grey"> (frei) </font> || ||<br />
|-<br />
| 10.50.32.26 || Test-PI || Statische IP des RasPI für Testzwecke || [[Benutzer:Hobo|Hobo]] <br />
|-<br />
| 10.50.32.27 || Test-IP || Statische IP für Testzwecke || [[Benutzer:Green|Green]] <br />
|-<br />
| 10.50.32.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.32.70 || testbridgeap.bridge.fff.community || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.71 || testbridgeclient.bridge.fff.community || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.100 || MicroNAS || anonymous FTP (10GB) || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.101 || Wetterstation || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Daten bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.102 || Wetterkamera || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Bilder bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.109 || Raspi || Raspi Server im Höffner || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.110 || - || - || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.111 || stmichael.bridge.ws13.fff.community || Nanobeam M5 Bridge als AP auf St. Michael Richtung DelphiN || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.112 || ws13.bridge.stmichael.fff.community || Nanobeam M5 Bridge als Client bei DelphiN. Richtung St. Michael || [[Benutzer:delphiN|delphiN]], [[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.113 || || Bridge als AP auf St. Michael. Richtung Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.114 || || Bridge als Client bei Hoeffner. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.118 || || ToughSwitch auf WS13 || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.119 || || ToughSwitch auf StMichael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.120 || || ToughSwitch im Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.121 || || Bridge als AP auf St. Michael. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.150 || ChristianD's PC || FFF-Netz ohne Internet || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.151 || feste Laptop IP || Für Speedtests mit manuellen Gateway || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.152 || RasPi || Testsystem || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.170 || HoeffnerPrinter || Drucker Computerraum Höffner || [[Benutzer:delphiN|delphiN]] <br />
|}<br />
<br />
=== Hood Nürnberg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.40.0 – 10.50.40.255 || || IP-Bereich Nürnberg Hood || <br />
|-<br />
| <strike>10.50.40.2</strike> || <strike>nue1.freifunk-franken.de</strike> || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.40.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.40.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.40.7 || fff-gw-yaga|| || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.40.8 || fff-bbg|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.10 || FFF-GW-M1 || || [[Server#FFF-GW-M1|Details]]<br />
|-<br />
| 10.50.40.11 || a.ns.franken.ff || DNS PoC - Master || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.12 || b.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.20 || - – - || Direct Connect HUB || [[Benutzer:TheFroggy|TheFroggy]]<br />
|-<br />
| 10.50.40.21 || rns1.franken.ff || DNS PoC - Recursor #1 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.22 || rns2.franken.ff || DNS PoC - Recursor #2 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| <strike>10.50.40.40</strike> || <strike>fff-synology.freifunk-franken.de</strike> || Umgezogen nach NBGLand || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.40.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.40.66 || flightradar.freifunk-franken.de || Dump1090 || [[Benutzer:Sixkiller6kl|sixkiller6kl]]<br />
|-<br />
| 10.50.40.98 || jabber.pm-ib.de || Jabber-Server || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.101 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.102 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.103 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.110 || ff_br_Spenglerstr || 5-GHz-Bridge Spenglerstr --> Johannis || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.111 || ff_Johannis || 5-GHz-Bridge Johannis --> Spenglerstr || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.120 || -- || 5-GHz-Access Point (Schniegling) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.121 || -- || 5-GHz-Client (Naturfreundehaus Nürnberg Mitte) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.130 || ff_nhgbr_Johnny || 5-GHz-Master (Standort Spenglerstr) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.131 || ff_nhgbr_NHG || 5-GHz-Slave (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.132 || ff_NHG_Osten || 5-GHz-Master (Standort Nachbarschaftshaus Goho, Richtung Osten) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.135 || ff_nhgswitch_NHG || POE-Switch (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.140 || ff_TS_PoE_tmp || 5-Port POE-Switch (für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.141 || ff_NS_M5_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.142 || ff_NS_M5_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.143 || ff_PB_5AC_500_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.144 || ff_PB_5AC_500_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.145 || ff_nhgbrsüd_M5loco_Master || 5-GHz-Master (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.146 || ff_Bauerngassebr_M5loco_Slave || 5-GHz-Slave (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.200 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Client, Routerfernwartung || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.201 – 10.50.40.205|| Test || bitte vorläufig freihalten, danke || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.230 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.231 ||???.franken.ff || Juniper SRX (VRF) || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.232 ||???.franken.ff || Raspberry Pi || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.233 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.234 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
| 10.50.43.165 || fffsvr01.franken.freifunk.net || SMB, FTP Server 250GB || [[Benutzer:ManuelS|ManuelS]]<br />
|}<br />
<br />
=== Hood Ansbach ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.48.0 – 10.50.48.255 || || IP-Bereich Ansbach Hood || <br />
|-<br />
| 10.50.48.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.48.3 || fff-gw-cdfue1 || || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| 10.50.48.20 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.21 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.48.230 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.231 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.232 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.233 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.234 || || mom. nur Test || JuzeCr<br />
|}<br />
<br />
=== Hood Hassberge ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.56.0 – 10.50.56.255 || || IP-Bereich Hassberge Hood || <br />
|-<br />
| 10.50.56.2 || <strike> nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]] </strike><br />
|-<br />
| 10.50.56.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.56.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.56.7 || fff-roffl|| || [[Server#fff-roffl|Details]]<br />
|-<br />
| 10.50.56.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| Bitte den Bereich 10.50.56.120 – 10.50.56.129 für [[Benutzer:Plocker|Plocker]] frei lassen<br />
|-<br />
| 10.50.56.123 || Teeworlds-Game-Server || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.124 || OwnCloud + Wiki || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.125 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.126 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.132 ||<strike> Webserver + MUD? || || [[Benutzer:PeterPhilipp|area52]]</strike><br />
|}<br />
<br />
=== Hood Hassberge Süd ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.60.0 – 10.50.60.255 || || IP-Bereich HassbergeSued Hood ||<br />
|-<br />
| 10.50.60.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.60.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.60.7 || fff-roffl|| || [[Server#fff-roffl|Details]] <br />
|-<br />
| 10.50.60.10 || Webcam Meehäusle Parkplatz|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.11 || Webcam Meehäusle Biergarten|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.100 /mediawiki || Webserver Mediawiki (in progress: Wikipedia(de)offline mirror)|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.101 /wiki || Raspi Webserver mit MediaWiki (Haßberge Wiki)|| || [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Erlangen ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.64.0 – 10.50.64.255 || || IP-Bereich Erlangen Hood || <br />
|-<br />
| 10.50.64.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.64.3 || fff-gw-yaga || || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.64.4 || fff-gw-kwadro || || [[Server#fff-gw-kwadro|Details]]<br />
|-<br />
| 10.50.64.10 || radiator.franken.ff || || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.11 || voip-1.radiator.franken.ff || VoIP mittels SIP || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.12 || cam-1.radiator.franken.ff || IP-Cam || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.20 || radiatrix.franken.ff || geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.21 || cam-1.radiatrix.franken.ff || IP-Cam, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.22 || voip-1.radiatrix.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.30 || long.franken.ff || geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.31 || cam-1.long.franken.ff || IP-Cam, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.33 || voip-1.long.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.40 |||| Streaming Erlangen (im Aufbau) || [[Benutzer:R.funkt|R.funkt]]<br />
|-<br />
| 10.50.64.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.64.60 || gate3 || Dev || [[Benutzer:Jonas-bebe|Jonas-bebe]]<br />
<br />
|}<br />
<br />
=== Hood Würzburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.72.0 – 10.50.79.255 || || IP-Bereich Würzburg Hood || <br />
|-<br />
| 10.50.72.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.72.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.72.6 || fff-wue1|| || [[Server#fff-wue1|Details]] <br />
|-<br />
| 10.50.72.7 || kleeV2|| || [[Server#kleeV2|Details]] <br />
|-<br />
| 10.50.72.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.72.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood BGL ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.80.0 – 10.50.87.255 || || IP-Bereich BGL Hood || <br />
|-<br />
| 10.50.80.1 || watzmann || ||<br />
|-<br />
| 10.50.80.2 || staufen || ||<br />
|}<br />
<br />
=== Hood Nürnberger-Land ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.88.0 – 10.50.95.255 || || IP-Bereich NbgLand Hood || <br />
|-<br />
| 10.50.88.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.88.10 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.40 || fff-synology.freifunk-franken.de || Umzug nach Hood-Teilung || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.88.170 ||???.franken.ff || 5-GHz Richtfunk AP || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.171 ||???.franken.ff || 5-GHz Richtfunk Client || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.172 ||???.franken.ff || VM zum Testen || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood Aux ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
!10.50.240.1 – 10.50.247.254 || || IP-Bereich aux Hood || <br />
|-<br />
| 10.50.240.1 || fff-bbg || ||<br />
|-<br />
| 10.50.240.2 || fff-fra1 || ||<br />
|-<br />
| 10.50.240.7 || kleeV2 || ||<br />
|-<br />
| 10.50.240.20 || || Testgateway Flo für Hotel Busch |||<br />
|-<br />
| 10.50.240.11 || AP.bridge1.hoeffner.fff.community || Bridge AP Höffner || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.12 || S01.bridge1.hoeffner.fff.community || Bridge Station Hardhöhe || [[Benutzer:delphiN|delphiN]] ||<br />
|}</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Portal:Netz&diff=5567
Portal:Netz
2016-02-07T08:18:35Z
<p>Green: /* Liste der Subnetze */</p>
<hr />
<div>== Das Netz ==<br />
Eine Karte der aktiven Router gibt es [https://netmon.freifunk-franken.de/map.php hier].<br />
<br />
Eine Karte der Hoods ist [http://keyserver.freifunk-franken.de/fff/voronoimap.php hier] zu finden.<br />
<br />
Die [https://netmon.freifunk-franken.de/routerlist.php Liste der Router] kann dank Netmon immer live verfolgt werden. Infos über die Schreibweise (z.B. "/20") gibt es in der [http://de.wikipedia.org/wiki/CIDR Wikipedia].<br />
<br />
=== Gateway ===<br />
Erste Versuche einer sinnvollen Aufteilung von Gateways. Erweiterungen und Verbesserungen sind jederzeit erwünscht. [https://pad.freifunk.net/p/Gatewayaufteilung-Franken Zum Pad]<br />
<br />
== IP-Netz ==<br />
Mit der Netz-Umstellung vom 22.03.2014 haben wir nicht mehr länger ein großes [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_2_.E2.80.93_Sicherungsschicht_.28Data_Link_Layer.29 Layer-II-Netz], welches durch das [https://de.wikipedia.org/wiki/B.A.T.M.A.N. B.A.T.M.A.N. advanced]-Protokoll geroutet wird. Seitdem gibt es mehrere [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_3_.E2.80.93_Vermittlungsschicht_.28Network_Layer.29 Layer-III-Netze] (Hoods). Ein Layer-III-Netz entsteht grundsätzlich, indem hier ein Subnetz eingetragen wird. Wie dabei genau vorgegangen wird, steht in [[HoodVerwaltung]].<br />
Für jedes Subnetz muss separat abgewogen werden, wie groß es werden wird und wo es dann in die bestehenden Subnetze am besten eingegliedert werden kann.<br />
<br />
==== DHCP ====<br />
[[Datei:Hoods.png|200px|thumb|right|Vorschlag für die Hood-Organisation]]<br />
Damit simple Clients das neue Subnetz nutzen können, muss ein eigener DHCP-Server pro Subnetz bereit gestellt werden. Es macht dabei häufig Sinn, das Subnetz in IP-Bereiche aufzuteilen, die von mehreren DHCP-Servern verteilt werden. Ein zweiter DHCP-Server ermöglicht zum einen eine Lastverteilung, zum anderen erhöht sich die Ausfallsicherheit. Der DHCP-Server muss den Clients ein Default-Gateway und mindestens einen DNS-Server zuweisen. Da das Default-Gateway ebenfalls innerhalb des Subnetzes liegen muss, bietet es sich an, den selben Server, auf dem das DHCP läuft, zu nutzen.<br />
<br />
==== OLSR-Router ====<br />
Das Subnetz muss anschließend an das vorhandene Freifunknetz angeschlossen werden. Dazu muss eine Verbindung zu einem bestehenden OLSR-Router aufgebaut werden. Dies kann eine VPN-Verbindung, aber auch eine Wifi-Verbindung sein und muss individuell zwischen den zwei Parteien ausgehandelt werden. Es kann sinnvoll sein, Verbindungen zu mehr als einem OLSR-Router zu haben. Sobald der eigene Router an das OLSR-Netz angebunden ist, ist er selbst ein OLSR-Router.<br />
<br />
An den eigenen OLSR-Router können nun Accesspoints angeschlossen werden. Dies kann per VPN, WLAN, Kabel oder anderweitig geschehen. Es ist auch möglich, den Accesspoint selbst als OLSR-Router anzubinden. Auch diese Konfiguration ist individuell zu klären. Ein Accesspoint kann ein (oder mehrere) einfacher Wifi-AP oder auch ein Array von mehreren B.A.T.M.A.N.-Knoten sein. Es sollte vermieden werden, dass sich Subnetze vermischen. Dies würde immer dann passieren, wenn zwei Layer-II-Netze, die eigentlich unterschiedliche Subnetze verteilen, verbunden werden. Besonders beim B.A.T.M.A.N.-Protokoll besteht hier leicht diese Gefahr; daher sollte für jedes Subnetz eine eigene BSSID und ESSID gewählt werden.<br />
<br />
==== Aus Routersicht ====<br />
Nur Router in einer Hood können sich per B.A.T.M.A.N. advanced vermaschen, sowohl per VPN, also auch per WLAN. Daher müssen Router die räumlich nahe beieinander stehen auch in derselben Hood sein. Durch das Vermaschen des Netzes wird allerdings auch Verwaltungs-Verkehr erzeugt (Overhead). Je größer die Hood, desto größer der Overhead.<br />
<br />
Eine Verbindung zwischen Routern in unterschiedlichen Hoods ist per IP (OSI Schicht 3) möglich.<br />
<br />
Wenn im Netmon kein Standort eingegeben wurde, dann landet der Router in der Dafault-Hood.<br />
<br />
==== Monitoring (Netmon) ====<br />
Aktuell können sich Knoten nur über ein IPv6-Link-Local-Interface beim Netmon anmelden und Netmon kann die Knoten nur über eine IPv6-Link-Local-Adresse abfragen. Hier muss ein neuer Mechanismus gefunden werden, der es ermöglicht, die Knoten über Subnetze hinweg anzusprechen.<br />
<br />
Als Workaround ist es möglich, über einen Layer-II-Tunnel zum Netmon-Server das Subnetz an das Netmon anzubinden. Auf dem Netmon-Server werden alle Subnetze in einem Bridge-Interface zusammengefasst, welches keine Pakete weiterleiten kann.<br />
<br />
==== Wireless-LAN ====<br />
Wir haben uns auf folgende WLAN-Parameter verständigt:<br />
'''ESSID: franken.freifunk.net'''. Kanal 1.<br />
<br />
== Liste der Subnetze ==<br />
{|<br />
! !! Bereich !! Bereitgestellt durch<br />
|-<br />
! 10.50.0.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.0.1 – 10.50.15.254</font> || <br />
|-<br />
! 10.50.16.0/20 || Default Hood ||<br />
|-<br />
| || 10.50.16.1 – 10.50.17.255 || Statische Adressen<br />
|-<br />
| || 10.50.18.0 – 10.50.19.255 || --<br />
|-<br />
| || 10.50.20.0 – 10.50.21.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey">10.50.22.0 – 10.50.23.254 </font> || <br />
|-<br />
| || <font color="grey">10.50.24.0 – 10.50.31.254 </font> || <br />
|-<br />
! 10.50.32.0/21 || Fürth Hood ||<br />
|-<br />
| || 10.50.32.1 – 10.50.32.255 || Statische Adressen<br />
|-<br />
| || <font color="grey"> 10.50.33.0 – 10.50.34.255 </font> || --<br />
|-<br />
| || 10.50.35.0 – 10.50.36.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey"> 10.50.37.0 – 10.50.37.255 </font> || --<br />
|-<br />
| || 10.50.38.0 – 10.50.39.254 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.40.0/21 || Nürnberg Hood ||<br />
|-<br />
| || 10.50.40.1 – 10.50.40.255 || Statische Adressen<br />
|-<br />
| || 10.50.41.0 – 10.50.42.255 || [[Server#FFF-GW-M1|FFF-GW-M1]]<br />
|-<br />
| || <font color="grey"> 10.50.43.0 - 10.50.43.255 </font> || <br />
|-<br />
| || 10.50.44.0 – 10.50.44.255 || (umgezogen) [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| ||10.50.45.0 – 10.50.46.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.47.0 – 10.50.47.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.48.0/21 || Ansbach Hood ||<br />
|-<br />
| || 10.50.48.1 – 10.50.48.255 || Statische Adressen<br />
|-<br />
| || 10.50.49.0 – 10.50.50.255 || <br />
|-<br />
| || 10.50.51.0 – 10.50.52.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.53.0 – 10.50.54.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| || <font color="grey">10.50.55.0 – 10.50.55.254</font> || <br />
|-<br />
! 10.50.56.0/22 || Hassberge Hood ||<br />
|-<br />
| || 10.50.56.1 – 10.50.56.255 || Statische Adressen<br />
|-<br />
| || 10.50.57.0 – 10.50.57.255 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
| || 10.50.58.0 – 10.50.58.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.59.0 – 10.50.59.254 || [[Server#fff-has|fff-has]]<br />
|-<br />
! 10.50.60.0/22 || HassbergeSued Hood ||<br />
|-<br />
| || 10.50.60.1 – 10.50.60.255 || Statische Adressen<br />
|-<br />
| || 10.50.61.0 – 10.50.61.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
| || 10.50.62.0 – 10.50.62.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.63.0 – 10.50.63.254 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
! 10.50.64.0/21 || Erlangen Hood ||<br />
|-<br />
| || 10.50.64.1 – 10.50.64.255 || Statische Adressen<br />
|-<br />
| || 10.50.65.0 – 10.50.66.255 || [[Server#fff-gw-kwadro|fff-gw-kwadro]]<br />
|-<br />
| || 10.50.67.0 – 10.50.68.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.69.0 – 10.50.71.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.72.0/21 || Würzburg Hood ||<br />
|-<br />
| || 10.50.72.1 – 10.50.72.255 || Statische Adressen<br />
|-<br />
| || <font color="grey"> 10.50.73.0 – 10.50.74.255 </font>|| <br />
|-<br />
| || 10.50.75.0 – 10.50.76.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.77.0 – 10.50.77.255 || [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || <font color="grey"> 10.50.78.0 – 10.50.78.255 </font>|| <br />
|-<br />
| || 10.50.79.0 – 10.50.79.254 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
! 10.50.80.0/21 || BGL ||<br />
|-<br />
| || 10.50.80.1 – 10.50.80.255 || Statische Adressen<br />
|-<br />
| || 10.50.81.0 – 10.50.82.255 || [[Server#watzmann|watzmann]]<br />
|-<br />
| || 10.50.83.0 – 10.50.84.255 || [[Server#staufen|staufen]]<br />
|-<br />
! 10.50.88.0/21 || NbgLand Hood ||<br />
|-<br />
| || 10.50.88.1 – 10.50.88.255 || Statische Adressen<br />
|-<br />
| || 10.50.89.0 – 10.50.89.255 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| || <font color="grey">10.50.90.0 - 10.50.93.255</font> || <br />
|-<br />
| || 10.50.94.0 – 10.50.95.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.96.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.96.1 – 10.50.127.254</font> || <br />
|-<br />
! 10.50.128.0/24 || Test von Casandro ||<br />
|-<br />
| || 10.50.128.20 – 10.50.128.200 || 10.50.128.1<br />
|-<br />
! 10.50.129.0/24 || free ||<br />
|-<br />
| || || <br />
|-<br />
! 10.50.130.0/24 || free ||<br />
|-<br />
| || <font color="black">10.50.130.1 – 10.50.130.254</font> || Testbereich ChristianD für [https://wiki.freifunk-franken.de/w/Standorte/Fuerth/Unterfuerberg/L3Konzept Konzept Unterfürberg]<br />
|-<br />
! 10.50.131.0/24 || free ||<br />
|-<br />
| || <font color="grey">10.50.131.1 – 10.50.131.254</font> || <br />
|-<br />
! 10.50.132.0/22 || border:none gateway ||<br />
|-<br />
| || 10.50.132.1 – 10.50.132.255 || Statische Adressen<br />
|-<br />
| || 10.50.133.0 – 10.50.134.255 || DHCP<br />
|-<br />
| || <font color="grey">10.50.135.0 – 10.50.135.254</font> || frei<br />
|-<br />
! 10.50.136.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.136.1 – 10.50.143.254</font> || <br />
|-<br />
! 10.50.144.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.144.1 – 10.50.159.254</font> || <br />
|-<br />
! 10.50.160.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.160.1 – 10.50.191.254</font> || <br />
|-<br />
! 10.50.192.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.192.1 – 10.50.223.254</font> || <br />
|-<br />
! 10.50.224.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.224.1 – 10.50.239.254</font> || <br />
|-<br />
! 10.50.240.0/20 ||Aufgeteilt: || <br />
|-<br />
! 10.50.240.0/21 || fffaux ||<br />
|-<br />
| || 10.50.240.1 – 10.50.240.255 || Statische Adressen<br />
|-<br />
| || 10.50.241.0 – 10.50.241.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.242.0 – 10.50.243.255 || [[Server#fff-fra1|fff-fra1]]<br />
|-<br />
| || 10.50.244.0 – 10.50.244.127 || Testinstallation Busch (Flo)<br />
|-<br />
| || 10.50.244.128 - 10.50.245.255 || | [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || <font color="grey">10.50.246.0 - 10.50.247.254</font> || <br />
|-<br />
<br />
! 10.50.248.0/22 || free ||<br />
|-<br />
| || 10.50.248.1 – 10.50.248.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.249.0 - 10.50.251.254</font> || <br />
|-<br />
! 10.50.252.0/22 || TUNNEL ||<br />
|-<br />
| || 10.50.252.0 fff_ro1 || 10.50.252.1 nue1 || <br />
|-<br />
| || 10.50.252.2 fff_ro1 || 10.50.252.3 watzmann || <br />
|-<br />
| || 10.50.252.4 fff_ro1 || 10.50.252.5 staufen || <br />
|-<br />
| || 10.50.252.6 fff_ro1 || 10.50.252.7 has2 || <br />
|-<br />
| || 10.50.252.8 fff_ro1 || 10.50.252.9 has || <br />
|-<br />
| || 10.50.252.10 ro1 || 10.50.252.11 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.12 fff-has2 || 10.50.252.13 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.14 fff-gw-m1 || 10.50.252.15 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.16 KleeV2 || 10.50.252.17 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.18 KleeV2 || 10.50.252.19 nue1 ||<br />
|-<br />
| || 10.50.252.20 KleeV2 || 10.50.252.21 ro1 ||<br />
|-<br />
| || 10.50.252.22 fff-gw-yaga || 10.50.252.23 fff-wue1 ||<br />
|-<br />
| || 10.50.252.24 fff-gw-m1 || 10.50.252.25 fff-has2 ||<br />
|-<br />
| || 10.50.252.26 fff-gw-m1 || 10.50.252.27 fff-wue1 ||<br />
|-<br />
| || 10.50.252.28 fff-bbg || 10.50.252.29 fff-nue1 ||<br />
|-<br />
| || 10.50.252.30 fff-bbg || 10.50.252.31 fff-ro1 ||<br />
|-<br />
| || 10.50.252.32 fff-bbg || 10.50.252.33 fff-has2 ||<br />
|-<br />
| || 10.50.252.34 fff-bbg || 10.50.252.35 KleeV2 ||<br />
|-<br />
| || 10.50.252.36 fff-wue1 || 10.50.252.37 fff-bbg ||<br />
|-<br />
| || 10.50.252.38 fff-gw-m1 || 10.50.252.39 ro1 ||<br />
|-<br />
| || 10.50.252.40 fff-gw-yaga || 10.50.252.41 ro1 ||<br />
|-<br />
| || 10.50.252.42 fff-gw-yaga || 10.50.252.43 nue1 ||<br />
|-<br />
| || 10.50.252.44 fff-roffl || 10.50.252.45 fff-has2 ||<br />
|-<br />
| || 10.50.252.46 fff-fra1 || 10.50.252.47 fff-bbg ||<br />
|-<br />
| || 10.50.252.48 fff-fra1 || 10.50.252.49 kleeV2 ||<br />
|-<br />
| || 10.50.252.50 fff-roffl || 10.50.252.51 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.52 fff-has2 || 10.50.252.53 kleeV2 ||<br />
|-<br />
| || 10.50.252.54 fff-has2 || 10.50.252.55 fff-fra1 ||<br />
|-<br />
| || 10.50.252.56 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.57 kwadronaut ||<br />
|-<br />
| || 10.50.252.58 fff-gw-m1 || 10.50.252.59 kwadronaut ||<br />
|-<br />
| || 10.50.252.60 fff-nue1 || 10.50.252.61 kwadronaut ||<br />
|-<br />
| || 10.50.252.62 ro1 || 10.50.252.63 kwadronaut ||<br />
|-<br />
| || 10.50.252.64 staufen || 10.50.252.65 kwadronaut ||<br />
|-<br />
| || 10.50.252.66 watzmann || 10.50.252.67 kwadronaut ||<br />
|-<br />
| || 10.50.252.68 kwadronaut || 10.50.252.69 yaga ||<br />
|-<br />
| || 10.50.252.250 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.251 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.252 Testsystem von [[Benutzer:ChristianD]] || 10.50.252.253 Testsystem2 von [[Benutzer:ChristianD]] ||<br />
|-<br />
! 10.83.0.0/16 || free for tests ||<br />
|-<br />
| || <font color="grey">10.83.0.1 - 10.83.255.254</font> || <br />
|-<br />
|}<br />
<br />
== Statische IP-Adressen ==<br />
Dienste müssen Ihre IP-Adressen natürlich aus dem Subnetz beziehen, in welchem sie angeschlossen sind. Damit es keine Konflikte gibt, muss die IP-Adresse hier registriert werden.<br />
<br />
=== Default Hood ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.16.0 – 10.50.17.255 || || IP-Bereich Default Hood || <br />
|-<br />
| 10.50.16.2 || fff-nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.16.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.16.11 || c.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.21 || rns3.franken.ff || DNS PoC - Recursor #3 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.16.100 || netmon.freifunk-franken.de || || [[Server#si1|Details]]<br />
|-<br />
| 10.50.16.112 ||???.franken.ff || Raspberry Pi, Test owncloud, FTP || MartinS<br />
|-<br />
| 10.50.16.128 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.150 ||Diagnose ChristianD || Diagnose ChristianD || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.16.200 ||???.franken.ff || Fileserver || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.16.212 ||???.franken.ff || NAS, verschiedene Services || JomJom<br />
|-<br />
| 10.50.16.222 ||???.franken.ff || VM, mom. nur Test || pixelchrome<br />
|-<br />
| 10.50.17.17 ||???.franken.ff || Teamspeak, sFTP, owncloud im Test || Johnny<br />
|-<br />
| 10.50.17.112 ||???.franken.ff || Webserver, Tests || wolli112<br />
|}<br />
<br />
=== Hood Fürth ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.32.0 – 10.50.32.255 || || IP-Bereich Fürth Hood || <br />
|-<br />
| 10.50.32.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.32.3 || fff-uk1.freifunk-franken.de || || [[Server#fff-uk1|Details]]<br />
|-<br />
| 10.50.32.4 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|- <br />
| <font color="grey">10.50.32.5</font> || <font color="grey"> (frei) </font> || || <br />
|- <br />
| <font color="grey">10.50.32.6</font> || <font color="grey"> (frei) </font> || || <br />
|- <br />
| 10.50.32.7 || kleeV2 || ||<br />
|-<br />
| 10.50.32.26 || Test-PI || Statische IP des RasPI für Testzwecke || [[Benutzer:Hobo|Hobo]] <br />
|-<br />
| 10.50.32.27 || Test-IP || Statische IP für Testzwecke || [[Benutzer:Green|Green]] <br />
|-<br />
| 10.50.32.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.32.70 || testbridgeap.bridge.fff.community || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.71 || testbridgeclient.bridge.fff.community || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.100 || MicroNAS || anonymous FTP (10GB) || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.101 || Wetterstation || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Daten bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.102 || Wetterkamera || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Bilder bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.109 || Raspi || Raspi Server im Höffner || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.110 || - || - || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.111 || stmichael.bridge.ws13.fff.community || Nanobeam M5 Bridge als AP auf St. Michael Richtung DelphiN || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.112 || ws13.bridge.stmichael.fff.community || Nanobeam M5 Bridge als Client bei DelphiN. Richtung St. Michael || [[Benutzer:delphiN|delphiN]], [[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.113 || || Bridge als AP auf St. Michael. Richtung Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.114 || || Bridge als Client bei Hoeffner. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.118 || || ToughSwitch auf WS13 || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.119 || || ToughSwitch auf StMichael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.120 || || ToughSwitch im Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.121 || || Bridge als AP auf St. Michael. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.150 || ChristianD's PC || FFF-Netz ohne Internet || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.151 || feste Laptop IP || Für Speedtests mit manuellen Gateway || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.152 || RasPi || Testsystem || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.170 || HoeffnerPrinter || Drucker Computerraum Höffner || [[Benutzer:delphiN|delphiN]] <br />
|}<br />
<br />
=== Hood Nürnberg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.40.0 – 10.50.40.255 || || IP-Bereich Nürnberg Hood || <br />
|-<br />
| <strike>10.50.40.2</strike> || <strike>nue1.freifunk-franken.de</strike> || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.40.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.40.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.40.7 || fff-gw-yaga|| || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.40.8 || fff-bbg|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.10 || FFF-GW-M1 || || [[Server#FFF-GW-M1|Details]]<br />
|-<br />
| 10.50.40.11 || a.ns.franken.ff || DNS PoC - Master || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.12 || b.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.20 || - – - || Direct Connect HUB || [[Benutzer:TheFroggy|TheFroggy]]<br />
|-<br />
| 10.50.40.21 || rns1.franken.ff || DNS PoC - Recursor #1 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.22 || rns2.franken.ff || DNS PoC - Recursor #2 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| <strike>10.50.40.40</strike> || <strike>fff-synology.freifunk-franken.de</strike> || Umgezogen nach NBGLand || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.40.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.40.66 || flightradar.freifunk-franken.de || Dump1090 || [[Benutzer:Sixkiller6kl|sixkiller6kl]]<br />
|-<br />
| 10.50.40.98 || jabber.pm-ib.de || Jabber-Server || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.101 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.102 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.103 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.110 || ff_br_Spenglerstr || 5-GHz-Bridge Spenglerstr --> Johannis || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.111 || ff_Johannis || 5-GHz-Bridge Johannis --> Spenglerstr || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.120 || -- || 5-GHz-Access Point (Schniegling) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.121 || -- || 5-GHz-Client (Naturfreundehaus Nürnberg Mitte) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.130 || ff_nhgbr_Johnny || 5-GHz-Master (Standort Spenglerstr) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.131 || ff_nhgbr_NHG || 5-GHz-Slave (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.132 || ff_NHG_Osten || 5-GHz-Master (Standort Nachbarschaftshaus Goho, Richtung Osten) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.135 || ff_nhgswitch_NHG || POE-Switch (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.140 || ff_TS_PoE_tmp || 5-Port POE-Switch (für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.141 || ff_NS_M5_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.142 || ff_NS_M5_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.143 || ff_PB_5AC_500_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.144 || ff_PB_5AC_500_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.145 || ff_nhgbrsüd_M5loco_Master || 5-GHz-Master (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.146 || ff_Bauerngassebr_M5loco_Slave || 5-GHz-Slave (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.200 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Client, Routerfernwartung || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.201 – 10.50.40.205|| Test || bitte vorläufig freihalten, danke || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.230 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.231 ||???.franken.ff || Juniper SRX (VRF) || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.232 ||???.franken.ff || Raspberry Pi || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.233 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.234 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
| 10.50.43.165 || fffsvr01.franken.freifunk.net || SMB, FTP Server 250GB || [[Benutzer:ManuelS|ManuelS]]<br />
|}<br />
<br />
=== Hood Ansbach ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.48.0 – 10.50.48.255 || || IP-Bereich Ansbach Hood || <br />
|-<br />
| 10.50.48.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.48.3 || fff-gw-cdfue1 || || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| 10.50.48.20 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.21 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.48.230 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.231 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.232 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.233 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.234 || || mom. nur Test || JuzeCr<br />
|}<br />
<br />
=== Hood Hassberge ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.56.0 – 10.50.56.255 || || IP-Bereich Hassberge Hood || <br />
|-<br />
| 10.50.56.2 || <strike> nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]] </strike><br />
|-<br />
| 10.50.56.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.56.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.56.7 || fff-roffl|| || [[Server#fff-roffl|Details]]<br />
|-<br />
| 10.50.56.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| Bitte den Bereich 10.50.56.120 – 10.50.56.129 für [[Benutzer:Plocker|Plocker]] frei lassen<br />
|-<br />
| 10.50.56.123 || Teeworlds-Game-Server || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.124 || OwnCloud + Wiki || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.125 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.126 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.132 ||<strike> Webserver + MUD? || || [[Benutzer:PeterPhilipp|area52]]</strike><br />
|}<br />
<br />
=== Hood Hassberge Süd ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.60.0 – 10.50.60.255 || || IP-Bereich HassbergeSued Hood ||<br />
|-<br />
| 10.50.60.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.60.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.60.7 || fff-roffl|| || [[Server#fff-roffl|Details]] <br />
|-<br />
| 10.50.60.10 || Webcam Meehäusle Parkplatz|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.11 || Webcam Meehäusle Biergarten|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.100 /mediawiki || Webserver Mediawiki (in progress: Wikipedia(de)offline mirror)|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.101 /wiki || Raspi Webserver mit MediaWiki (Haßberge Wiki)|| || [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Erlangen ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.64.0 – 10.50.64.255 || || IP-Bereich Erlangen Hood || <br />
|-<br />
| 10.50.64.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.64.3 || fff-gw-yaga || || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.64.4 || fff-gw-kwadro || || [[Server#fff-gw-kwadro|Details]]<br />
|-<br />
| 10.50.64.10 || radiator.franken.ff || || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.11 || voip-1.radiator.franken.ff || VoIP mittels SIP || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.12 || cam-1.radiator.franken.ff || IP-Cam || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.20 || radiatrix.franken.ff || geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.21 || cam-1.radiatrix.franken.ff || IP-Cam, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.22 || voip-1.radiatrix.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.30 || long.franken.ff || geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.31 || cam-1.long.franken.ff || IP-Cam, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.33 || voip-1.long.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.40 |||| Streaming Erlangen (im Aufbau) || [[Benutzer:R.funkt|R.funkt]]<br />
|-<br />
| 10.50.64.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.64.60 || gate3 || Dev || [[Benutzer:Jonas-bebe|Jonas-bebe]]<br />
<br />
|}<br />
<br />
=== Hood Würzburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.72.0 – 10.50.79.255 || || IP-Bereich Würzburg Hood || <br />
|-<br />
| 10.50.72.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.72.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.72.6 || fff-wue1|| || [[Server#fff-wue1|Details]] <br />
|-<br />
| 10.50.72.7 || kleeV2|| || [[Server#kleeV2|Details]] <br />
|-<br />
| 10.50.72.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.72.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood BGL ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.80.0 – 10.50.87.255 || || IP-Bereich BGL Hood || <br />
|-<br />
| 10.50.80.1 || watzmann || ||<br />
|-<br />
| 10.50.80.2 || staufen || ||<br />
|}<br />
<br />
=== Hood Nürnberger-Land ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.88.0 – 10.50.95.255 || || IP-Bereich NbgLand Hood || <br />
|-<br />
| 10.50.88.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.88.10 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.40 || fff-synology.freifunk-franken.de || Umzug nach Hood-Teilung || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.88.170 ||???.franken.ff || 5-GHz Richtfunk AP || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.171 ||???.franken.ff || 5-GHz Richtfunk Client || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.172 ||???.franken.ff || VM zum Testen || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood Aux ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
!10.50.240.1 – 10.50.247.254 || || IP-Bereich aux Hood || <br />
|-<br />
| 10.50.240.1 || fff-bbg || ||<br />
|-<br />
| 10.50.240.2 || fff-fra1 || ||<br />
|-<br />
| 10.50.240.7 || kleeV2 || ||<br />
|-<br />
| 10.50.240.20 || || Testgateway Flo für Hotel Busch |||<br />
|-<br />
| 10.50.240.11 || AP.bridge1.hoeffner.fff.community || Bridge AP Höffner || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.12 || S01.bridge1.hoeffner.fff.community || Bridge Station Hardhöhe || [[Benutzer:delphiN|delphiN]] ||<br />
|}</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Portal:Netz&diff=5509
Portal:Netz
2016-02-03T19:20:22Z
<p>Green: /* Liste der Subnetze */</p>
<hr />
<div>== Das Netz ==<br />
Eine Karte der aktiven Router gibt es [https://netmon.freifunk-franken.de/map.php hier].<br />
<br />
Eine Karte der Hoods ist [http://keyserver.freifunk-franken.de/fff/voronoimap.php hier] zu finden.<br />
<br />
Die [https://netmon.freifunk-franken.de/routerlist.php Liste der Router] kann dank Netmon immer live verfolgt werden. Infos über die Schreibweise (z.B. "/20") gibt es in der [http://de.wikipedia.org/wiki/CIDR Wikipedia].<br />
<br />
=== Gateway ===<br />
Erste Versuche einer sinnvollen Aufteilung von Gateways. Erweiterungen und Verbesserungen sind jederzeit erwünscht. [https://pad.freifunk.net/p/Gatewayaufteilung-Franken Zum Pad]<br />
<br />
== IP-Netz ==<br />
Mit der Netz-Umstellung vom 22.03.2014 haben wir nicht mehr länger ein großes [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_2_.E2.80.93_Sicherungsschicht_.28Data_Link_Layer.29 Layer-II-Netz], welches durch das [https://de.wikipedia.org/wiki/B.A.T.M.A.N. B.A.T.M.A.N. advanced]-Protokoll geroutet wird. Seitdem gibt es mehrere [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_3_.E2.80.93_Vermittlungsschicht_.28Network_Layer.29 Layer-III-Netze] (Hoods). Ein Layer-III-Netz entsteht grundsätzlich, indem hier ein Subnetz eingetragen wird. Wie dabei genau vorgegangen wird, steht in [[HoodVerwaltung]].<br />
Für jedes Subnetz muss separat abgewogen werden, wie groß es werden wird und wo es dann in die bestehenden Subnetze am besten eingegliedert werden kann.<br />
<br />
==== DHCP ====<br />
[[Datei:Hoods.png|200px|thumb|right|Vorschlag für die Hood-Organisation]]<br />
Damit simple Clients das neue Subnetz nutzen können, muss ein eigener DHCP-Server pro Subnetz bereit gestellt werden. Es macht dabei häufig Sinn, das Subnetz in IP-Bereiche aufzuteilen, die von mehreren DHCP-Servern verteilt werden. Ein zweiter DHCP-Server ermöglicht zum einen eine Lastverteilung, zum anderen erhöht sich die Ausfallsicherheit. Der DHCP-Server muss den Clients ein Default-Gateway und mindestens einen DNS-Server zuweisen. Da das Default-Gateway ebenfalls innerhalb des Subnetzes liegen muss, bietet es sich an, den selben Server, auf dem das DHCP läuft, zu nutzen.<br />
<br />
==== OLSR-Router ====<br />
Das Subnetz muss anschließend an das vorhandene Freifunknetz angeschlossen werden. Dazu muss eine Verbindung zu einem bestehenden OLSR-Router aufgebaut werden. Dies kann eine VPN-Verbindung, aber auch eine Wifi-Verbindung sein und muss individuell zwischen den zwei Parteien ausgehandelt werden. Es kann sinnvoll sein, Verbindungen zu mehr als einem OLSR-Router zu haben. Sobald der eigene Router an das OLSR-Netz angebunden ist, ist er selbst ein OLSR-Router.<br />
<br />
An den eigenen OLSR-Router können nun Accesspoints angeschlossen werden. Dies kann per VPN, WLAN, Kabel oder anderweitig geschehen. Es ist auch möglich, den Accesspoint selbst als OLSR-Router anzubinden. Auch diese Konfiguration ist individuell zu klären. Ein Accesspoint kann ein (oder mehrere) einfacher Wifi-AP oder auch ein Array von mehreren B.A.T.M.A.N.-Knoten sein. Es sollte vermieden werden, dass sich Subnetze vermischen. Dies würde immer dann passieren, wenn zwei Layer-II-Netze, die eigentlich unterschiedliche Subnetze verteilen, verbunden werden. Besonders beim B.A.T.M.A.N.-Protokoll besteht hier leicht diese Gefahr; daher sollte für jedes Subnetz eine eigene BSSID und ESSID gewählt werden.<br />
<br />
==== Aus Routersicht ====<br />
Nur Router in einer Hood können sich per B.A.T.M.A.N. advanced vermaschen, sowohl per VPN, also auch per WLAN. Daher müssen Router die räumlich nahe beieinander stehen auch in derselben Hood sein. Durch das Vermaschen des Netzes wird allerdings auch Verwaltungs-Verkehr erzeugt (Overhead). Je größer die Hood, desto größer der Overhead.<br />
<br />
Eine Verbindung zwischen Routern in unterschiedlichen Hoods ist per IP (OSI Schicht 3) möglich.<br />
<br />
Wenn im Netmon kein Standort eingegeben wurde, dann landet der Router in der Dafault-Hood.<br />
<br />
==== Monitoring (Netmon) ====<br />
Aktuell können sich Knoten nur über ein IPv6-Link-Local-Interface beim Netmon anmelden und Netmon kann die Knoten nur über eine IPv6-Link-Local-Adresse abfragen. Hier muss ein neuer Mechanismus gefunden werden, der es ermöglicht, die Knoten über Subnetze hinweg anzusprechen.<br />
<br />
Als Workaround ist es möglich, über einen Layer-II-Tunnel zum Netmon-Server das Subnetz an das Netmon anzubinden. Auf dem Netmon-Server werden alle Subnetze in einem Bridge-Interface zusammengefasst, welches keine Pakete weiterleiten kann.<br />
<br />
==== Wireless-LAN ====<br />
Wir haben uns auf folgende WLAN-Parameter verständigt:<br />
'''ESSID: franken.freifunk.net'''. Kanal 1.<br />
<br />
== Liste der Subnetze ==<br />
{|<br />
! !! Bereich !! Bereitgestellt durch<br />
|-<br />
! 10.50.0.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.0.1 – 10.50.15.254</font> || <br />
|-<br />
! 10.50.16.0/20 || Default Hood ||<br />
|-<br />
| || 10.50.16.1 – 10.50.17.255 || Statische Adressen<br />
|-<br />
| || 10.50.18.0 – 10.50.19.255 || --<br />
|-<br />
| || 10.50.20.0 – 10.50.21.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey">10.50.22.0 – 10.50.23.254 </font> || <br />
|-<br />
| || <font color="grey">10.50.24.0 – 10.50.31.254 </font> || <br />
|-<br />
! 10.50.32.0/21 || Fürth Hood ||<br />
|-<br />
| || 10.50.32.1 – 10.50.32.255 || Statische Adressen<br />
|-<br />
| || 10.50.33.0 – 10.50.34.255 || --<br />
|-<br />
| || 10.50.35.0 – 10.50.36.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.37.0 – 10.50.37.255 || [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || 10.50.38.0 – 10.50.39.254 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.40.0/21 || Nürnberg Hood ||<br />
|-<br />
| || 10.50.40.1 – 10.50.40.255 || Statische Adressen<br />
|-<br />
| || 10.50.41.0 – 10.50.42.255 || [[Server#FFF-GW-M1|FFF-GW-M1]]<br />
|-<br />
| || <font color="grey"> 10.50.43.0 - 10.50.43.255 </font> || <br />
|-<br />
| || 10.50.44.0 – 10.50.44.255 || (umgezogen) [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| ||10.50.45.0 – 10.50.46.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.47.0 – 10.50.47.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.48.0/21 || Ansbach Hood ||<br />
|-<br />
| || 10.50.48.1 – 10.50.48.255 || Statische Adressen<br />
|-<br />
| || 10.50.49.0 – 10.50.50.255 || <br />
|-<br />
| || 10.50.51.0 – 10.50.52.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.53.0 – 10.50.54.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| || <font color="grey">10.50.55.0 – 10.50.55.254</font> || <br />
|-<br />
! 10.50.56.0/22 || Hassberge Hood ||<br />
|-<br />
| || 10.50.56.1 – 10.50.56.255 || Statische Adressen<br />
|-<br />
| || 10.50.57.0 – 10.50.57.255 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
| || 10.50.58.0 – 10.50.58.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.59.0 – 10.50.59.254 || [[Server#fff-has|fff-has]]<br />
|-<br />
! 10.50.60.0/22 || HassbergeSued Hood ||<br />
|-<br />
| || 10.50.60.1 – 10.50.60.255 || Statische Adressen<br />
|-<br />
| || 10.50.61.0 – 10.50.61.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
| || 10.50.62.0 – 10.50.62.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.63.0 – 10.50.63.254 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
! 10.50.64.0/21 || Erlangen Hood ||<br />
|-<br />
| || 10.50.64.1 – 10.50.64.255 || Statische Adressen<br />
|-<br />
| || 10.50.65.0 – 10.50.66.255 || [[Server#fff-gw-kwadro|fff-gw-kwadro]]<br />
|-<br />
| || 10.50.67.0 – 10.50.68.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.69.0 – 10.50.71.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.72.0/21 || Würzburg Hood ||<br />
|-<br />
| || 10.50.72.1 – 10.50.72.255 || Statische Adressen<br />
|-<br />
| || <font color="grey"> 10.50.73.0 – 10.50.74.255 </font>|| <br />
|-<br />
| || 10.50.75.0 – 10.50.76.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.77.0 – 10.50.77.255 || [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || <font color="grey"> 10.50.78.0 – 10.50.78.255 </font>|| <br />
|-<br />
| || 10.50.79.0 – 10.50.79.254 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
! 10.50.80.0/21 || BGL ||<br />
|-<br />
| || 10.50.80.1 – 10.50.80.255 || Statische Adressen<br />
|-<br />
| || 10.50.81.0 – 10.50.82.255 || [[Server#watzmann|watzmann]]<br />
|-<br />
| || 10.50.83.0 – 10.50.84.255 || [[Server#staufen|staufen]]<br />
|-<br />
! 10.50.88.0/21 || NbgLand Hood ||<br />
|-<br />
| || 10.50.88.1 – 10.50.88.255 || Statische Adressen<br />
|-<br />
| || 10.50.89.0 – 10.50.89.255 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| || <font color="grey">10.50.90.0 - 10.50.93.255</font> || <br />
|-<br />
| || 10.50.94.0 – 10.50.95.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.96.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.96.1 – 10.50.127.254</font> || <br />
|-<br />
! 10.50.128.0/24 || Test von Casandro ||<br />
|-<br />
| || 10.50.128.20 – 10.50.128.200 || 10.50.128.1<br />
|-<br />
! 10.50.129.0/24 || free ||<br />
|-<br />
| || || <br />
|-<br />
! 10.50.130.0/24 || free ||<br />
|-<br />
| || <font color="black">10.50.130.1 – 10.50.130.254</font> || Testbereich ChristianD für [https://wiki.freifunk-franken.de/w/Standorte/Fuerth/Unterfuerberg/L3Konzept Konzept Unterfürberg]<br />
|-<br />
! 10.50.131.0/24 || free ||<br />
|-<br />
| || <font color="grey">10.50.131.1 – 10.50.131.254</font> || <br />
|-<br />
! 10.50.132.0/22 || border:none gateway ||<br />
|-<br />
| || 10.50.132.1 – 10.50.132.255 || Statische Adressen<br />
|-<br />
| || 10.50.133.0 – 10.50.134.255 || DHCP<br />
|-<br />
| || <font color="grey">10.50.135.0 – 10.50.135.254</font> || frei<br />
|-<br />
! 10.50.136.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.136.1 – 10.50.143.254</font> || <br />
|-<br />
! 10.50.144.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.144.1 – 10.50.159.254</font> || <br />
|-<br />
! 10.50.160.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.160.1 – 10.50.191.254</font> || <br />
|-<br />
! 10.50.192.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.192.1 – 10.50.223.254</font> || <br />
|-<br />
! 10.50.224.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.224.1 – 10.50.239.254</font> || <br />
|-<br />
! 10.50.240.0/20 ||Aufgeteilt: || <br />
|-<br />
! 10.50.240.0/21 || fffaux ||<br />
|-<br />
| || 10.50.240.1 – 10.50.240.255 || Statische Adressen<br />
|-<br />
| || 10.50.241.0 – 10.50.241.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.242.0 – 10.50.243.255 || [[Server#fff-fra1|fff-fra1]]<br />
|-<br />
| || 10.50.244.0 – 10.50.244.127 || Testinstallation Busch (Flo)<br />
|-<br />
| || 10.50.244.128 - 10.50.245.255 || | [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || <font color="grey">10.50.246.0 - 10.50.247.254</font> || <br />
|-<br />
<br />
! 10.50.248.0/22 || free ||<br />
|-<br />
| || 10.50.248.1 – 10.50.248.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.249.0 - 10.50.251.254</font> || <br />
|-<br />
! 10.50.252.0/22 || TUNNEL ||<br />
|-<br />
| || 10.50.252.0 fff_ro1 || 10.50.252.1 nue1 || <br />
|-<br />
| || 10.50.252.2 fff_ro1 || 10.50.252.3 watzmann || <br />
|-<br />
| || 10.50.252.4 fff_ro1 || 10.50.252.5 staufen || <br />
|-<br />
| || 10.50.252.6 fff_ro1 || 10.50.252.7 has2 || <br />
|-<br />
| || 10.50.252.8 fff_ro1 || 10.50.252.9 has || <br />
|-<br />
| || 10.50.252.10 ro1 || 10.50.252.11 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.12 fff-has2 || 10.50.252.13 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.14 fff-gw-m1 || 10.50.252.15 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.16 KleeV2 || 10.50.252.17 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.18 KleeV2 || 10.50.252.19 nue1 ||<br />
|-<br />
| || 10.50.252.20 KleeV2 || 10.50.252.21 ro1 ||<br />
|-<br />
| || 10.50.252.22 fff-gw-yaga || 10.50.252.23 fff-wue1 ||<br />
|-<br />
| || 10.50.252.24 fff-gw-m1 || 10.50.252.25 fff-has2 ||<br />
|-<br />
| || 10.50.252.26 fff-gw-m1 || 10.50.252.27 fff-wue1 ||<br />
|-<br />
| || 10.50.252.28 fff-bbg || 10.50.252.29 fff-nue1 ||<br />
|-<br />
| || 10.50.252.30 fff-bbg || 10.50.252.31 fff-ro1 ||<br />
|-<br />
| || 10.50.252.32 fff-bbg || 10.50.252.33 fff-has2 ||<br />
|-<br />
| || 10.50.252.34 fff-bbg || 10.50.252.35 KleeV2 ||<br />
|-<br />
| || 10.50.252.36 fff-wue1 || 10.50.252.37 fff-bbg ||<br />
|-<br />
| || 10.50.252.38 fff-gw-m1 || 10.50.252.39 ro1 ||<br />
|-<br />
| || 10.50.252.40 fff-gw-yaga || 10.50.252.41 ro1 ||<br />
|-<br />
| || 10.50.252.42 fff-gw-yaga || 10.50.252.43 nue1 ||<br />
|-<br />
| || 10.50.252.44 fff-roffl || 10.50.252.45 fff-has2 ||<br />
|-<br />
| || 10.50.252.46 fff-fra1 || 10.50.252.47 fff-bbg ||<br />
|-<br />
| || 10.50.252.48 fff-fra1 || 10.50.252.49 kleeV2 ||<br />
|-<br />
| || 10.50.252.50 fff-roffl || 10.50.252.51 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.52 fff-has2 || 10.50.252.53 kleeV2 ||<br />
|-<br />
| || 10.50.252.54 fff-has2 || 10.50.252.55 fff-fra1 ||<br />
|-<br />
| || 10.50.252.56 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.57 kwadronaut ||<br />
|-<br />
| || 10.50.252.58 fff-gw-m1 || 10.50.252.59 kwadronaut ||<br />
|-<br />
| || 10.50.252.60 fff-nue1 || 10.50.252.61 kwadronaut ||<br />
|-<br />
| || 10.50.252.62 ro1 || 10.50.252.63 kwadronaut ||<br />
|-<br />
| || 10.50.252.64 staufen || 10.50.252.65 kwadronaut ||<br />
|-<br />
| || 10.50.252.66 watzmann || 10.50.252.67 kwadronaut ||<br />
|-<br />
| || 10.50.252.68 kwadronaut || 10.50.252.69 yaga ||<br />
|-<br />
| || 10.50.252.250 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.251 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.252 Testsystem von [[Benutzer:ChristianD]] || 10.50.252.253 Testsystem2 von [[Benutzer:ChristianD]] ||<br />
|-<br />
! 10.83.0.0/16 || free for tests ||<br />
|-<br />
| || <font color="grey">10.83.0.1 - 10.83.255.254</font> || <br />
|-<br />
|}<br />
<br />
== Statische IP-Adressen ==<br />
Dienste müssen Ihre IP-Adressen natürlich aus dem Subnetz beziehen, in welchem sie angeschlossen sind. Damit es keine Konflikte gibt, muss die IP-Adresse hier registriert werden.<br />
<br />
=== Default Hood ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.16.0 – 10.50.17.255 || || IP-Bereich Default Hood || <br />
|-<br />
| 10.50.16.2 || fff-nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.16.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.16.11 || c.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.21 || rns3.franken.ff || DNS PoC - Recursor #3 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.16.100 || netmon.freifunk-franken.de || || [[Server#si1|Details]]<br />
|-<br />
| 10.50.16.112 ||???.franken.ff || Raspberry Pi, Test owncloud, FTP || MartinS<br />
|-<br />
| 10.50.16.128 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.150 ||Diagnose ChristianD || Diagnose ChristianD || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.16.200 ||???.franken.ff || Fileserver || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.16.212 ||???.franken.ff || NAS, verschiedene Services || JomJom<br />
|-<br />
| 10.50.16.222 ||???.franken.ff || VM, mom. nur Test || pixelchrome<br />
|-<br />
| 10.50.17.17 ||???.franken.ff || Teamspeak, sFTP, owncloud im Test || Johnny<br />
|-<br />
| 10.50.17.112 ||???.franken.ff || Webserver, Tests || wolli112<br />
|}<br />
<br />
=== Hood Fürth ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.32.0 – 10.50.32.255 || || IP-Bereich Fürth Hood || <br />
|-<br />
| 10.50.32.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.32.3 || fff-uk1.freifunk-franken.de || || [[Server#fff-uk1|Details]]<br />
|-<br />
| 10.50.32.4 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|- <br />
| <font color="grey">10.50.32.5</font> || <font color="grey"> (frei) </font> || || <br />
|- <br />
| <font color="grey">10.50.32.6</font> || <font color="grey"> (frei) </font> || || <br />
|- <br />
| 10.50.32.7 || kleeV2 || ||<br />
|-<br />
| 10.50.32.26 || Test-PI || Statische IP des RasPI für Testzwecke || [[Benutzer:Hobo|Hobo]] <br />
|-<br />
| 10.50.32.27 || Test-IP || Statische IP für Testzwecke || [[Benutzer:Green|Green]] <br />
|-<br />
| 10.50.32.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.32.70 || testbridgeap.bridge.fff.community || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.71 || testbridgeclient.bridge.fff.community || || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.100 || MicroNAS || anonymous FTP (10GB) || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.101 || Wetterstation || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Daten bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.102 || Wetterkamera || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Bilder bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.110 || - || - || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.111 || stmichael.bridge.ws13.fff.community || Nanobeam M5 Bridge als AP auf St. Michael Richtung DelphiN || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.112 || ws13.bridge.stmichael.fff.community || Nanobeam M5 Bridge als Client bei DelphiN. Richtung St. Michael || [[Benutzer:delphiN|delphiN]], [[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.113 || || Bridge als AP auf St. Michael. Richtung Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.114 || || Bridge als Client bei Hoeffner. Richtung St. Michael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]],[[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.118 || || ToughSwitch auf WS13 || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.119 || || ToughSwitch auf StMichael || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.120 || || ToughSwitch im Hoeffner || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.121 || || Bridge als AP auf St. Michael. Richtung Europaallee || [[Benutzer:delphiN|delphiN]],[[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.32.150 || ChristianD's PC || FFF-Netz ohne Internet || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.151 || feste Laptop IP || Für Speedtests mit manuellen Gateway || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.152 || RasPi || Testsystem || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.32.170 || HoeffnerPrinter || Drucker Computerraum Höffner || [[Benutzer:delphiN|delphiN]] <br />
|}<br />
<br />
=== Hood Nürnberg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.40.0 – 10.50.40.255 || || IP-Bereich Nürnberg Hood || <br />
|-<br />
| <strike>10.50.40.2</strike> || <strike>nue1.freifunk-franken.de</strike> || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.40.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.40.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.40.7 || fff-gw-yaga|| || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.40.8 || fff-bbg|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.10 || FFF-GW-M1 || || [[Server#FFF-GW-M1|Details]]<br />
|-<br />
| 10.50.40.11 || a.ns.franken.ff || DNS PoC - Master || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.12 || b.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.20 || - – - || Direct Connect HUB || [[Benutzer:TheFroggy|TheFroggy]]<br />
|-<br />
| 10.50.40.21 || rns1.franken.ff || DNS PoC - Recursor #1 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.22 || rns2.franken.ff || DNS PoC - Recursor #2 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| <strike>10.50.40.40</strike> || <strike>fff-synology.freifunk-franken.de</strike> || Umgezogen nach NBGLand || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.40.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.40.66 || flightradar.freifunk-franken.de || Dump1090 || [[Benutzer:Sixkiller6kl|sixkiller6kl]]<br />
|-<br />
| 10.50.40.98 || jabber.pm-ib.de || Jabber-Server || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.101 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.102 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.103 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.110 || ff_br_Spenglerstr || 5-GHz-Bridge Spenglerstr --> Johannis || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.111 || ff_Johannis || 5-GHz-Bridge Johannis --> Spenglerstr || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.120 || -- || 5-GHz-Access Point (Schniegling) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.121 || -- || 5-GHz-Client (Naturfreundehaus Nürnberg Mitte) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.130 || ff_nhgbr_Johnny || 5-GHz-Master (Standort Spenglerstr) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.131 || ff_nhgbr_NHG || 5-GHz-Slave (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.132 || ff_NHG_Osten || 5-GHz-Master (Standort Nachbarschaftshaus Goho, Richtung Osten) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.135 || ff_nhgswitch_NHG || POE-Switch (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.140 || ff_TS_PoE_tmp || 5-Port POE-Switch (für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.141 || ff_NS_M5_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.142 || ff_NS_M5_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.143 || ff_PB_5AC_500_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.144 || ff_PB_5AC_500_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.145 || ff_nhgbrsüd_M5loco_Master || 5-GHz-Master (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.146 || ff_Bauerngassebr_M5loco_Slave || 5-GHz-Slave (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.200 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Client, Routerfernwartung || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.201 – 10.50.40.205|| Test || bitte vorläufig freihalten, danke || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.230 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.231 ||???.franken.ff || Juniper SRX (VRF) || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.232 ||???.franken.ff || Raspberry Pi || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.233 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.234 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
| 10.50.43.165 || fffsvr01.franken.freifunk.net || SMB, FTP Server 250GB || [[Benutzer:ManuelS|ManuelS]]<br />
|}<br />
<br />
=== Hood Ansbach ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.48.0 – 10.50.48.255 || || IP-Bereich Ansbach Hood || <br />
|-<br />
| 10.50.48.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.48.3 || fff-gw-cdfue1 || || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| 10.50.48.20 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.21 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.48.230 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.231 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.232 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.233 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.234 || || mom. nur Test || JuzeCr<br />
|}<br />
<br />
=== Hood Hassberge ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.56.0 – 10.50.56.255 || || IP-Bereich Hassberge Hood || <br />
|-<br />
| 10.50.56.2 || <strike> nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]] </strike><br />
|-<br />
| 10.50.56.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.56.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.56.7 || fff-roffl|| || [[Server#fff-roffl|Details]]<br />
|-<br />
| 10.50.56.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| Bitte den Bereich 10.50.56.120 – 10.50.56.129 für [[Benutzer:Plocker|Plocker]] frei lassen<br />
|-<br />
| 10.50.56.123 || Teeworlds-Game-Server || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.124 || OwnCloud + Wiki || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.125 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.126 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.132 ||<strike> Webserver + MUD? || || [[Benutzer:PeterPhilipp|area52]]</strike><br />
|}<br />
<br />
=== Hood Hassberge Süd ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.60.0 – 10.50.60.255 || || IP-Bereich HassbergeSued Hood ||<br />
|-<br />
| 10.50.60.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.60.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.60.7 || fff-roffl|| || [[Server#fff-roffl|Details]] <br />
|-<br />
| 10.50.60.10 || Webcam Meehäusle Parkplatz|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.11 || Webcam Meehäusle Biergarten|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.100 /mediawiki || Webserver Mediawiki (in progress: Wikipedia(de)offline mirror)|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.101 /wiki || Raspi Webserver mit MediaWiki (Haßberge Wiki)|| || [[Benutzer:moexe|moexe]]<br />
|}<br />
<br />
=== Hood Erlangen ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.64.0 – 10.50.64.255 || || IP-Bereich Erlangen Hood || <br />
|-<br />
| 10.50.64.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.64.3 || fff-gw-yaga || || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.64.4 || fff-gw-kwadro || || [[Server#fff-gw-kwadro|Details]]<br />
|-<br />
| 10.50.64.10 || radiator.franken.ff || || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.11 || voip-1.radiator.franken.ff || VoIP mittels SIP || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.12 || cam-1.radiator.franken.ff || IP-Cam || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.20 || radiatrix.franken.ff || geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.21 || cam-1.radiatrix.franken.ff || IP-Cam, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.22 || voip-1.radiatrix.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.30 || long.franken.ff || geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.31 || cam-1.long.franken.ff || IP-Cam, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.33 || voip-1.long.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.40 |||| Streaming Erlangen (im Aufbau) || [[Benutzer:R.funkt|R.funkt]]<br />
|-<br />
| 10.50.64.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.64.60 || gate3 || Dev || [[Benutzer:Jonas-bebe|Jonas-bebe]]<br />
<br />
|}<br />
<br />
=== Hood Würzburg ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.72.0 – 10.50.79.255 || || IP-Bereich Würzburg Hood || <br />
|-<br />
| 10.50.72.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.72.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.72.6 || fff-wue1|| || [[Server#fff-wue1|Details]] <br />
|-<br />
| 10.50.72.7 || kleeV2|| || [[Server#kleeV2|Details]] <br />
|-<br />
| 10.50.72.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.72.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood BGL ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.80.0 – 10.50.87.255 || || IP-Bereich BGL Hood || <br />
|-<br />
| 10.50.80.1 || watzmann || ||<br />
|-<br />
| 10.50.80.2 || staufen || ||<br />
|}<br />
<br />
=== Hood Nürnberger-Land ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.88.0 – 10.50.95.255 || || IP-Bereich NbgLand Hood || <br />
|-<br />
| 10.50.88.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.88.10 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.40 || fff-synology.freifunk-franken.de || Umzug nach Hood-Teilung || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.88.170 ||???.franken.ff || 5-GHz Richtfunk AP || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.171 ||???.franken.ff || 5-GHz Richtfunk Client || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.172 ||???.franken.ff || VM zum Testen || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|}<br />
<br />
=== Hood Aux ===<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
!10.50.240.1 – 10.50.247.254 || || IP-Bereich aux Hood || <br />
|-<br />
| 10.50.240.1 || fff-bbg || ||<br />
|-<br />
| 10.50.240.2 || fff-fra1 || ||<br />
|-<br />
| 10.50.240.7 || kleeV2 || ||<br />
|-<br />
| 10.50.240.20 || || Testgateway Flo für Hotel Busch |||<br />
|-<br />
| 10.50.240.11 || AP.bridge1.hoeffner.fff.community || Bridge AP Höffner || [[Benutzer:delphiN|delphiN]] ||<br />
|-<br />
| 10.50.240.12 || S01.bridge1.hoeffner.fff.community || Bridge Station Hardhöhe || [[Benutzer:delphiN|delphiN]] ||<br />
|}</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Freifunk-Gateway_aufsetzen&diff=5362
Freifunk-Gateway aufsetzen
2016-01-23T14:06:22Z
<p>Green: /* OpenVPN Start/Stop Automatik */</p>
<hr />
<div>__TOC__<br />
[[Kategorie:Technik]]<br />
<br />
= Preface =<br />
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").<br />
<br />
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.<br />
<br />
Für Rat und Tat empfiehlt sich die Freifunk Franken Development Mailingliste.<br />
<br><br />
= Vorraussetzungen =<br />
* ssh-Zugang zum Server<br />
* Root Zugriff auf den Server. Entweder man ist "root" (Annahme in diesem Artikel) oder man kann Befehle mit "root-Rechten" durch ein vorgesetztes "sudo" ausführen sowie die Möglichkeit auf dem Server Kernelmodule zu laden (kann nicht jeder VServer!) <br />
* Grundlegende Netzwerkkenntnisse<br />
** IPv4 und Netzmaske<br />
** Devices<br />
** Routing (Default Route, Interfaces, Routing-Table) <br />
* Kentnisse <br />
** im Umgang mit Texteditoren (der im Artikel verwendete Editor kann durch beliebig andere ersetzt werden, z.B. durch "nano")<br />
** im Umgang mit der Linux Shell (z.B. Kommandozeilenparameter, Shell-Scripte, Umleitungen)<br />
** in der (selbständigen Nach-)Installation von (fehlenden) Software-Paketen<br />
** im Kompilieren von Software-Quellen<br />
<br><br />
= Referenzen / Andere Freifunk HowTo's =<br />
* http://wiki.freifunk.net/Freifunk_Hamburg/Gateway <br />
* http://wiki.mag.lab.sh/wiki/Freifunk_Fulda/Gateway<br />
<br><br />
= Anforderungen an Gateways =<br />
Die Anforderungen an das Gateway sind an sich niedrig. Wichtig ist, dass die Möglichkeit besteht, eigene Kernel-Module zu laden und das monatliche Traffic-Kontingent nicht zu niedrig ist. Entsprechend sind OpenVZ, Linux-vServer und ähnliche Containerlösungen nicht geeignet.<br />
<br />
Hardware:<br />
* CPU: 1x (64Bit)<br />
* RAM: 256MB .. 1GB<br />
* HDD: > 5 GB<br />
* NIC: 1x<br />
<br />
Software:<br />
* Debian Jessie (8) 64Bit Kernel <br />
* fastd v17<br />
* openvpn<br />
* B.A.T.M.A.N. adv 2013.4.0<br />
* dhcpd<br />
* olsr<br />
* bind9<br />
<br />
Pauschal gibt es keine Mindestanforderungen für den Trafficverbrauch. Es kommt sehr darauf an, wo der Server eingesetzt wird. <br />
'''Momentan suchen wir aber vor allem Server mit einem kostenlosen Traffic von mindestens 10-20 TB/Monat.'''<br />
<br><br />
== Anonymisierung (Störerhaftung) ==<br />
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.<br />
<br />
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. <br />
<br />
Folgende VPN-Anbieter sind zu diesem Zeitpunkt jedoch empfehlenswert:<br />
<br />
* [https://mullvad.net/en/ Mullvad] (Schweden, Niederlande)<br />
** Bis zu drei gleichzeitige Verbindungen<br />
** Kann man anonym mit Bitcoin bezahlen<br />
** Serverauswahl über die ausgelieferte OpenVPN-Konfiguration<br />
*** Server in den Niederlanden sind abends oft stark ausgelastet<br />
**(Gute Erfahrungen in Lübeck)<br />
<br />
* [https://integrityvpn.com/ Integrity VPN] (Schweden, Port80)<br />
** 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.<br />
**Hat eine überaus seriöse Webseite und eine Ltd. erfunden.™<br />
**Hat schon mal was von IPv6 gehört. Nutzt es zurzeit jedoch nur für SEO.<br />
**Blockiert Port 25 derzeit nicht.<br />
**Ist ein ein neuer Anbieter, der _bisher_ unausgelastet wirkt.<br />
** sind derzeit noch nicht nicht overselled und haben ihren Krams scheinbar halbwegs sauber konfiguriert<br />
<br />
* [https://ipredator.se/ Ipredator] (Schweden, Niederlande, Deutschland)<br />
** (Glänzen nicht durch Kompetenz, da sie lange Zeit nur PPTP angeboten haben)<br />
** Mögen schnelle Reconnects nicht -> manchmal muss man OpenVPN ein paar Stunden deaktivieren, bevor es wieder funktioniert.<br />
** Möchten bald auch IPv6 anbieten.<br />
** Angeblich Reseller von relakks<br />
<br />
Ungetestet:<br />
* [https://www.anonine.com/en Anonine VPN] (Portlane)<br />
* [https://privacy.io/ privacy.io] (Portlane)<br />
* [http://prq.se/?p=tunnel&intl=1 prq.se] (Eigenes Netz, teuer)<br />
* [http://arethusa.su/vpn.html Arethusa VPN] (Loggen in Frankreich, andere Server angeblich nicht)<br />
<br />
Einige Freifunknetze mieten auch VMs in Osteuropa. Da die VMs noch nicht an ihre Grezen stößt könnte man diese auch mitnutzen. Ansprechpartner wäre s0ma.<br />
<br><br />
== Anbindung an andere Netze ==<br />
Es gibt drei relativ relevante Netzwerke bei denen es sich lohnt, das lokale Netz damit zu verbinden:<br />
<br />
* InterCity-VPN zwischen den meisten Freifunknetzen<br />
** BGP<br />
** kleine Übsicht der http://www.ddmesh.de/topology/ic-vpn-verbindungen.html<br />
** Mehr Infos http://wiki.freifunk.net/IC-VPN<br />
<br />
* DN42<br />
** BGP<br />
** Experimentelles Darknet zur Erprobung von Routing-Technologien und so weiter, wird privat betrieben. Viel interessantes Zeugs™<br />
** 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.<br />
<br />
* ChaosVPN<br />
** Tinc<br />
** Relativ großes „Darknet“ zwischen vielen Hackerspaces auf der ganzen Welt.<br />
<br><br />
== vServer-Anbieter die empfehlenswert sind ==<br />
* [https://www.de-punkt.de/vserver.html de-punkt] (Databurg, FFM)<br />
** Schneller Speicher, gut bezahlbar, KVM, nur Traffic-Flat™® das übliche.<br />
* [http://www.hetzner.de/hosting/produktmatrix_vserver/vserver-produktmatrix Hetzner] (Falkenstein)<br />
** Bezahlbar, 6.90€/TB Extratraffic, KVM<br />
** Achtung: Die Netzwerkarte der VM ist aus Kompatibilitätsgründen auf e1000 gesetzt. Diese "Netzwerkkarte" kommt nicht mit den vielen UDP-Paketen von fastd zurecht. Deshalb muss man vor Verwendung als Gateway die Netzwerkkarte auf "virtio" stellen.<br />
* [http://colorhost.de/server/vserver/ colorhost] (über 23media, Global Switch, FFM)<br />
* Untersagt Nutzung für Freifunk (http://colorhost.de/server/vserver/kvm/small/)<br />
** Achtung: Nur Xen oder Xen HVM funktionieren<br />
* [http://www.xirra.net/en/v-server/productmatrix/ xirra] (Core-Backbone, NBG)<br />
** KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.<br />
* [http://buyvm.net/ BuyVM]<br />
** 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.<br />
* [http://webhod.de webhod]<br />
** 9,99 € für die kleinste KVM im Monat[https://www.webhod.de/de/vserver/kvm.html]<br />
<br><br />
== Server-Anbieter die '''nicht''' empfehlenswert sind ==<br />
* [http://www.wrzhost.com/ WRZhost]<br />
** 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.<br />
<br />
* [https://www.netcup.de/ netcup]<br />
** V-Server laufen zwar grundsätzlich gut, allerdings halten sie sich nicht an ihre Versprechungen. Server wurde bereits mehrfach gedrosselt obwohl der Traffic weit unter den versprochenen 80 Mbit/s war (zwischen 30 und 40 Mbit/s). Die Drosselung tritt ohne Vorwarnung in Kraft und man kann seinen Server nicht mehr erreichen. Entdrosselung nur auf Nachfrage und dann auch nur mit einigem hin und her.<br />
<br><br />
= Grundinstallation des Servers =<br />
Vom ausgesuchten Hoster lassen wir uns eine aktuelle Linux-Distribution installieren oder ausliefern, wobei sich die Anleitung auf ein Debian 8 / Jessie bezieht.<br />
<br><br />
== Repositories und Update ==<br />
Als erstes werfen wir einen Blick in...<br />
<br />
<code><br />
vi /etc/apt/sources.list<br />
</code><br />
<br />
...und schauen, inwieweit auf die gleichen Software-Repositories verwiesen wird:<br />
<br />
<pre> <br />
deb http://security.debian.org/ jessie/updates main<br />
deb-src http://security.debian.org/ jessie/updates main<br />
<br />
deb http://ftp.de.debian.org/debian/ jessie main contrib non-free<br />
deb-src http://ftp.de.debian.org/debian/ jessie main contrib non-free<br />
<br />
deb http://ftp.de.debian.org/debian/ jessie-updates main<br />
deb-src http://ftp.de.debian.org/debian/ jessie-updates main<br />
<br />
</pre><br />
<br />
Danach bringen wir das System auf einen aktuellen Stand:<br />
<br />
<code><br />
apt-get update<br />
<br />
apt-get upgrade<br />
</code><br />
<br><br />
== Sicherheit ==<br />
Den SSH-Zugang besser schützen durch:<br />
* Änderung des Ports<br />
* login nur mit key<br />
* Siehe [http://www.thomas-krenn.com/de/wiki/Absicherung_eines_Debian_Servers hier] für genaue Anleitung: <br />
<br />
<code><br />
apt-get install fail2ban<br />
</code><br />
<br />
und [http://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban_absichern einrichten]<br />
<br />
So,nun sollte der Server ausreichend abgesichert sein.<br />
<br><br />
== B.A.T.M.A.N. adv 2013.4.0 Kernel-Modul ==<br />
Batman-Adv aus Jessie ist zu neu. Hier muss manuell das alte B.A.T.M.A.N. advanced 2013.4.0 gebaut werden.<br />
<br />
Hierfür benötigen wir minimal die Paketquellen build-essential, linux-headers-amd64 und git:<br />
<br />
<code><br />
apt-get install build-essential linux-headers-amd64 git gnupg-curl<br />
</code><br />
<br />
Die Softwarequellen müssen heruntergeladen...<br />
<code><br />
cd ~<br />
<br />
git clone https://github.com/freifunk-gluon/batman-adv-legacy<br />
<br />
cd batman-adv-legacy<br />
</code><br />
<br />
... und kompiliert und installiert werden:<br />
<br />
<code><br />
make<br />
<br />
make install<br />
</code><br />
<br />
Hinweis: Sollten noch Paketquellen fehlen, wird dies während des Kompilierens gemeldet. Die Software-Quellen müssen nachinstalliert werden und der letzte Kompilierungs- und Installationsschritt so lange wiederholt werden, bis die Software erfolgreich erstellt wurde.<br />
<br />
Nach erfolgreicher Erstellung kann das B.A.T.M.A.N Kernel Modul per modprobe händisch eingebunden werden:<br />
<br />
<code><br />
modprobe batman-adv<br />
</code><br />
<br />
Es sollte dann im Kernel-log ....<br />
<code><br />
dmesg | grep batman_adv<br />
</code><br />
<br />
... mit einem Eintrag gelistet werden:<br />
<pre><br />
batman_adv: B.A.T.M.A.N. advanced 2013.4.0-21-ga854277-dirty (compatibility version 14) loaded<br />
</pre><br />
<br />
Das Kernelmodul von B.A.T.M.A.N. kann dann bei jedem Neustart des Systems geladen werden, indem in die Datei /etc/modules:<br />
<br />
<code><br />
vi /etc/modules<br />
</code><br />
<br />
..der Eintrag "batman-adv" hinzugefügt wird:<br />
<br />
<pre><br />
batman-adv<br />
</pre><br />
<br><br />
== B.A.T.M.A.N adv 2013.4.0 batctl ==<br />
Gleiches gilt für batctl, ein Kommandozeilenprogramm zur B.A.T.M.A.N Konfiguration. Die alte Version 2013.4.0 muss selber gebaut werden, da die Debian 8 / Jessie Paketquellen zu neu sind.<br />
<br />
Herunterladen und Entpacken der Softwarequellen:<br />
<code><br />
cd ~<br />
<br />
wget http://downloads.open-mesh.org/batman/releases/batman-adv-2013.4.0/batctl-2013.4.0.tar.gz<br />
<br />
tar xzf batctl-2013.4.0.tar.gz<br />
<br />
cd batctl-2013.4.0<br />
</code><br />
<br />
Kompilieren und Installieren:<br />
<br />
<code><br />
make<br />
<br />
make install<br />
</code><br />
<br />
Hinweis: Auch hier müssen ggf. fehlende Quellen händisch nachinstalliert und das Kompilieren und Installieren bis zum Erfolg wiederholt werden.<br />
<br><br />
== FastD ==<br />
Die Verbindung zwischen Gateway und Router wird über einen fastd-Tunnel realisiert.<br />
<br />
Hierfür müssen wir ein neues Repository in der Datei /etc/apt/sources.list deklarieren:<br />
<br />
<code><br />
vi /etc/apt/sources.list.d/universe-factory.list<br />
</code><br />
<br />
Dort fügen wir folgendes Repository an:<br />
<br />
<pre><br />
deb http://repo.universe-factory.net/debian/ sid main<br />
deb-src http://repo.universe-factory.net/debian/ sid main<br />
</pre><br />
<br />
Danach die PGP Schlüssel holen:<br />
<code><br />
gpg --keyserver hkps://hkps.pool.sks-keyservers.net --recv-key 16EF3F64CB201D9C<br />
<br />
gpg -a --export 16EF3F64CB201D9C | apt-key add -<br />
</code><br />
<br />
Datenbankupdate der Paketverwaltung:<br />
<code><br />
apt-get update<br />
</code><br />
<br />
Installation von fastd: <br />
<code><br />
apt-get install fastd <br />
</code><br />
<br><br />
<br />
== OpenVPN ==<br />
OpenVPN (falls benötigt) installieren wir mit:<br />
<code><br />
apt-get install openvpn<br />
</code><br />
<br><br />
== DHCP ==<br />
Den DHCP Server installieren wir mit:<br />
<code><br />
apt-get install isc-dhcp-server <br />
</code><br />
<br><br />
== Bind9 ==<br />
Als DNS Server nehmen wir hier den de-facto-Standard bind:<br />
<code><br />
apt-get install bind9 <br />
</code><br />
<br><br />
== OLSR ==<br />
Als Routing-Protokoll, um die einzelnen Hoods später zu einem Freifunk-Franken weit kommunizierenden Netz zu verbinden, wird OLSR installiert:<br />
<br />
<code><br />
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd_0.6.8.1-1_amd64.deb<br />
<br />
dpkg -i olsrd_0.6.8.1-1_amd64.deb<br />
<br />
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd-plugins_0.6.8.1-1_amd64.deb<br />
<br />
dpkg -i olsrd-plugins_0.6.8.1-1_amd64.deb<br />
<br />
</code><br />
<br><br />
= Konfigurieren des Freifunk-Gateways =<br />
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 />
<br><br />
== IPv4 des Gateways, IP-Bereich der Hood und DHCP Range des Gateway==<br />
Für das Gateway suchen wir uns unter [[Portal:Netz]] eine IPv4 Adresse aus dem statischen Range der Hood aus. Für Fürth läuft der Bereich für die statischen Adressen z.B. von 10.50.32.1 - 10.50.32.255. Hiervon suchen wir uns eine '''freie''' Adresse aus, und reservieren diese, indem wir sie weiter unten in die Tabelle der statischen IPs eintragen.<br />
<br />
Die Fürther Hood hat den IP-Bereich 10.50.32.0-10.50.32.255. Als Netzwerk wird dieser Bereich mit 10.50.32.0/21 deklariert, d.h. die ersten 21 Bit der IP identifizieren das Netzwerk "Fürther Hood" und die restlichen 11 Bit stehen zur IP Vergabe zur Verfügung, wobei Anfang (10.50.32.0) und Ende des Bereiches (10.50.39.255) reserviert sind und nicht, weder statisch noch dynamisch durch DHCP, belegt werden dürfen. Eine alternative Schreibweise zu 10.50.32.0/21 ist das Double "Network 10.50.32.0" und "Netmask 255.255.248.0". Ein entsprechender IP-Rechner zur analogen Anwendung in anderen Hoods findet sich z.B. [http://www.heise.de/netze/tools/netzwerkrechner/ hier].<br />
<br />
Ebenso sollte man einen DHCP-Bereich innerhalb des IP-Bereichs der jeweiligen Hood, die der GW bedienen soll, reservieren (d.h. in die oberer Tabelle unter [[Portal:Netz]] eintragen). Jeder DHCP-Server vergibt dynamisch IPv4 Adressen an Clients aus einem vorher definierten Adressbereich. Dieser Adressbereich sollte sich:<br />
* innerhalb des IP-Range der Hood bewegen<br />
* sich nicht mit dem Adressbereich überschneiden, den andere DHCP Server in der Hood verwalten<br />
* sich nicht mit dem Bereich der statischen Adressen der Hood überschneiden<br />
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. Vom gesamten IP-Bereich der Fürther Hood vergibt z.B. das Gateway fff-nue1 die Teilmenge 10.50.35.0 - 10.50.36.255 an Clients und teilt ihnen auf dem Weg auch gleich mit, wie sie Domain-Namen in IPs auflösen und auf welchem Weg sie ins Internet oder in andere Hoods kommen.<br />
<br><br />
== Routing Tabelle für Freifunk ==<br />
Fürs Routing im Freifunk Franken Netz wird eine eigene Routing Tabelle namens "fff" deklariert.<br />
<br />
Dies geschieht indem man in der Datei /etc/iproute2/rt_tables ...<br />
<code><br />
vi /etc/iproute2/rt_tables<br />
</code><br />
<br />
... folgendes am Ende einfügt:<br />
<br />
<pre><br />
10 fff<br />
</pre><br />
<br />
Unsere Freifunk Routing Tabelle lässt sich später durch<br />
<code><br />
ip route show table fff<br />
</code><br />
anzeigen, sobald wir die Tabelle mit Einträgen füllen.<br />
<br><br />
== B.A.T.M.A.N Netzwerk-Interface, fff Routingregeln und -tabelle ==<br />
'''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.<br />
<br />
In der Datei /etc/network/interfaces ...<br />
<br />
<code><br />
vi /etc/network/interfaces<br />
</code><br />
<br />
fügen wir zunächst folgenden Textblock des Gateways "klee" aus der Fürther Hood an:<br />
<br />
<pre><br />
.<br />
.<br />
.<br />
# device: bat0<br />
iface bat0 inet manual<br />
post-up ifconfig $IFACE up<br />
##Einschalten post-up:<br />
# IP des Gateways am B.A.T.M.A.N interface:<br />
post-up ip addr add 10.50.32.5/21 dev $IFACE<br />
# Regeln, wann die fff Routing-Tabelle benutzt werden soll: <br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.0.0.0/8 table fff <br />
post-up ip rule add to 10.0.0.0/8 table fff<br />
# Route in die Fuerther Hood: <br />
post-up ip route add 10.50.32.0/21 dev $IFACE table fff<br />
# Start des DHCP Servers:<br />
post-up invoke-rc.d isc-dhcp-server restart<br />
<br />
##Ausschalten post-down:<br />
# Loeschen von oben definieren Routen, Regeln und Interface: <br />
post-down ip route del 10.50.32.0/21 dev $IFACE table fff<br />
post-down ip rule del from 10.0.0.0/8 table fff<br />
post-down ip rule del to 10.0.0.0/8 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ifconfig $IFACE down<br />
<br />
# VPN Verbindung in die Fuerther Hood<br />
iface ffffuerthVPN inet manual<br />
post-up batctl -m bat0 if add $IFACE<br />
post-up ifconfig $IFACE up<br />
post-up ifup bat0<br />
post-down ifdown bat0<br />
post-down ifconfig $IFACE down<br />
</pre><br />
<br />
In diesem Beispiel sind:<br />
* IP des Gateway/Netzmaske der Fürther Hood: 10.50.32.5/21<br />
* IP des Netzwerks Fürther Hood / Netzmaske der Fürther Hood: 10.50.32.0/21.<br />
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.<br />
<br />
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.).<br />
<br />
Die Regeln definieren, das Traffic der<br />
* aus dem Netzwerk 10.0.0.0/8 kommt<br />
* das Netzwerk 10.0.0.0/8 zum Ziel hat<br />
* oder über die B.A.T.M.A.N Schnittstelle übermittelt wird<br />
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.<br />
<br />
Im post-down Abschnitt werden die vorher definierten Regeln, Interfaces und Routen wieder gelöscht.<br />
<br />
Der untere Abschnitt definiert einen VPN Tunnel in die Fürther Hood. Der Name des Interfaces im Beispiel (ffffuerthVPN) kann individuell neu vergeben werden.<br />
<br><br />
== FastD Start- und Verwaltungsscript ==<br />
Für die Konfiguration von fastd importieren wir eine Datei in ''/etc/fastd'' mit dem Befehl:<br />
<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/fff_beispiel_fastd.sh -P /etc/fastd/<br />
</code><br />
<br />
Alternativ kann das Skript aus einer leeren Datei erstellt werden:<br />
<code><br />
touch /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
danach öffnen wir diese:<br />
<br />
<code><br />
vi /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
und editieren das Skript oder fügen ein Neues ein:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
SERVERNAME="beispiel"<br />
<br />
hood="hoodeintragen"<br />
project="fff"<br />
port=10004<br />
<br />
SERVERNAME="$SERVERNAME.$hood"<br />
<br />
hostname=$SERVERNAME<br />
<br />
if [ ! -d /etc/fastd ]<br />
then<br />
mkdir /etc/fastd<br />
fi<br />
<br />
if [ ! -d /etc/fastd/$project.$hood ]<br />
then<br />
mkdir /etc/fastd/$project.$hood<br />
mkdir /etc/fastd/$project.$hood/peers<br />
<br />
#fastd config<br />
(<br />
echo "# Log warnings and errors to stderr"<br />
echo "log level error;"<br />
echo "# Log everything to a log file"<br />
echo "log to syslog as \"${project}${hood}\" level info;"<br />
echo "# Set the interface name"<br />
echo "interface \"${project}${hood}VPN\";"<br />
echo "# Support xsalsa20 and aes128 encryption methods, prefer xsalsa20"<br />
echo "#method \"xsalsa20-poly1305\";"<br />
echo "#method \"aes128-gcm\";"<br />
echo "method \"null\";"<br />
echo "# Bind to a fixed port, IPv4 only"<br />
echo "bind any:${port};"<br />
echo "# Secret key generated by \"fastd --generate-key\""<br />
echo "secret \"$(fastd --generate-key | grep -i Secret | awk '{print $2}')\";" <br />
echo "# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)" <br />
echo "# (see MTU selection documentation)" <br />
echo "mtu 1426;" <br />
echo "on up \"/etc/fastd/${project}.${hood}/up.sh\";" <br />
echo "on post-down \"/etc/fastd/${project}.${hood}/down.sh\";" <br />
echo "# Include peers from the directory 'peers'" <br />
echo "include peers from \"/etc/fastd/${project}.${hood}/peers\";" <br />
echo "secure handshakes no;"<br />
) >> "/etc/fastd/$project.$hood/$project.$hood.conf"<br />
<br />
#fastd-up<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifdown \$INTERFACE"<br />
) >> /etc/fastd/$project.$hood/down.sh<br />
<br />
chmod +x /etc/fastd/$project.$hood/down.sh<br />
<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifup \$INTERFACE" >> /etc/fastd/$project.$hood/up.sh<br />
) >> /etc/fastd/$project.$hood/up.sh<br />
chmod +x /etc/fastd/$project.$hood/up.sh<br />
fi<br />
<br />
pubkey=$(fastd -c /etc/fastd/$project.$hood/$project.$hood.conf --show-key --machine-readable)<br />
port=$(grep ^bind /etc/fastd/$project.$hood/$project.$hood.conf | cut -d: -f2 | cut -d\; -f1)<br />
<br />
# fire up<br />
if [ "$(/sbin/ifconfig -a | grep -i ethernet | grep ${project}${hood}VPN)" = "" ]<br />
then<br />
/bin/rm /var/run/fastd.$project.$hood.pid<br />
fastd -c /etc/fastd/$project.$hood/$project.$hood.conf -d --pid-file /var/run/fastd.$project.$hood.pid<br />
fi<br />
<br />
# register<br />
wget -T15 -q "http://keyserver.freifunk-franken.de/${project}/?name=$hostname&port=$port&key=$pubkey" -O /tmp/fastd_${project}.${hood}_output <br />
if [ "$?" != "0" ]<br />
then<br />
echo "Update failed"<br />
echo "Exiting, no clean up, no refresh"<br />
exit<br />
fi<br />
<br />
touch /tmp/fastd_${project}.${hood}_starting<br />
<br />
filenames=$(cat /tmp/fastd_${project}.${hood}_output| grep ^#### | sed -e 's/^####//' | sed -e 's/.conf//g')<br />
for file in $filenames<br />
do<br />
grep -A100 ^####$file.conf$ /tmp/fastd_${project}.${hood}_output | grep -v ^####$file.conf$ | grep -m1 ^### -B100 | grep -v ^### | sed 's/ float;/;/g' > "/etc/fastd/$project.$hood/peers/$file"<br />
echo 'float yes;' >> "/etc/fastd/$project.$hood/peers/$file"<br />
done<br />
<br />
#find old peers<br />
OLD=$(find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print)<br />
<br />
if [ -n "${OLD}" ] ; then<br />
echo "Lösche alte:"<br />
echo $OLD<br />
<br />
find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print | xargs /bin/rm /tmp/fastd_${project}.${hood}_starting<br />
fi<br />
<br />
#reload<br />
kill -HUP "$(cat /var/run/fastd.$project.$hood.pid)"<br />
<br />
exit 0<br />
</pre><br />
<br />
Zum Schluss geben wir noch ein<br />
<br />
<code><br />
chmod +x /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
ein, um das Skript ausführbar zu machen.<br />
<br />
Das Skript konfiguriert fastd, indem es<br />
* einen Schlüssel generiert, sollte keiner existieren<br />
* diesen Schlüssel mit dem Keyserver austauscht<br />
* die fastd Konfigurationsdatei anlegt<br />
* den fastd Dämonen startet<br />
<br />
Lediglich der Servername und die Hood müssen oben im Skript händisch angepasst werden. Der Dateiname des Skripts kann individuell angepasst werden.<br />
<br />
Nachdem das Script ausgeführt wurde, sollte man überprüfen ob das Interface in der Konfigurationsdatei unter /etc/fastd/fff.<Hoodname>/fff.<Hoodname>.conf das gleiche ist wie vorher in /etc/network/interfaces festgelegt. Wenn der Name nicht identisch ist (Groß-/Kleinschreibung), werden die Interfaces nicht starten.<br />
<br />
Hinweis: Das Gateway wird standardmässig in die Default-Hood eingebunden. Es wird hier lediglich ein Name für die Konfigurationsdatei und der Gateway Name definiert. Die Zuordnung des Gateways zu der Hood erfolgt später über den KeyXchange (siehe unten).<br />
<br><br />
== IP-Forwarding ==<br />
Um Anfragen, die das Gateway erreichen, weiterzuleiten, muss IP-Forwarding aktiviert werden. <br />
<br />
Manuell geht dies über:<br />
<code><br />
echo "1" > /proc/sys/net/ipv4/ip_forward<br />
<br />
echo "1" > /proc/sys/net/ipv6/conf/default/forwarding<br />
<br />
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding<br />
</code><br />
<br />
Dauerhaft lässt sich IP-Forwarding in /etc/sysctl.conf aktivieren:<br />
<code><br />
vi /etc/sysctl.conf<br />
</code><br />
<br />
.. um dort die Abschnitte einzukommentieren, die das Forwarding steuern:<br />
<pre><br />
.<br />
.<br />
.<br />
# Uncomment the next line to enable packet forwarding for IPv4<br />
net.ipv4.ip_forward=1<br />
<br />
# Uncomment the next line to enable packet forwarding for IPv6<br />
# Enabling this option disables Stateless Address Autoconfiguration<br />
# based on Router Advertisements for this host<br />
net.ipv6.conf.all.forwarding=1<br />
.<br />
.<br />
.<br />
</pre><br />
<br><br />
== Testen von B.A.T.M.A.N, fastd und Autostart ==<br />
Hierfür booten wir das Gateway am besten erst mal neu:<br />
<code><br />
reboot & exit<br />
</code><br />
<br />
und starten das fast.d Startskript manuell: <br />
<code><br />
/etc/fastd/fff_beispiel_fastd.sh &<br />
</code><br />
<br />
Beim Erststart werden Schlüsselpaare generiert und ausgetauscht, es kann also etwas dauern.<br />
<br />
Danach sollte der Aufruf von...<br />
<code><br />
pgrep fastd<br />
</code><br />
... mit der Prozess-ID beantwortet werden: Fastd läuft in dem Fall.<br />
<br />
<br />
Ein Aufruf von ifconfig:<br />
<code><br />
ifconfig<br />
</code><br />
<br />
sollte die neu erstellten Interfaces bat0 und ffffuerthVPN zurückliefern.<br />
Exemplarisch und als Auszug:<br />
<pre><br />
bat0 Link encap:Ethernet HWaddr ea:95:50:07:f7:27 <br />
inet addr:10.50.32.5 Bcast:0.0.0.0 Mask:255.255.248.0<br />
inet6 addr: fe80::e895:50ff:fe07:f727/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:1089992 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:849698 errors:0 dropped:1728 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0 <br />
RX bytes:141311612 (134.7 MiB) TX bytes:1052934594 (1004.1 MiB)<br />
<br />
.<br />
.<br />
.<br />
ffffuerthVPN Link encap:Ethernet HWaddr e6:3b:f3:b7:fc:db <br />
inet6 addr: fe80::e43b:f3ff:feb7:fcdb/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1426 Metric:1<br />
RX packets:32389694 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:2699525 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:500 <br />
RX bytes:4193328694 (3.9 GiB) TX bytes:1384843740 (1.2 GiB)<br />
.<br />
.<br />
.<br />
</pre><br />
Aus dem ifconfig Auszug für bat0 sollte die eingerichtete IP des Gateways und die Netzmaske hervorgehen.<br />
<br />
<br />
Die Abfrage der IP-Regeln:<br />
<code><br />
ip rule<br />
</code><br />
<br />
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):<br />
<pre><br />
32757: from all to 10.0.0.0/8 lookup fff <br />
32758: from 10.0.0.0/8 lookup fff <br />
32759: from all iif bat0 lookup fff <br />
</pre><br />
<br />
Eine Abfrage der fff-Routing Tabelle<br />
<code><br />
ip route show table fff <br />
</code><br />
<br />
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:<br />
<pre><br />
10.50.32.0/21 dev bat0 scope link<br />
</pre><br />
<br />
Ein Aufruf von "batctl o"<br />
<code><br />
batctl o <br />
</code><br />
<br />
ergibt eine Liste der MAC-Adressen von unseren nächsten Nachbarn. Exemplarisch und als Auszug:<br />
<pre><br />
[B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: ffffuerthVPN/e6:3b:f3:b7:fc:db (bat0)]<br />
Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ...<br />
96:43:c4:2e:73:68 0.004s (255) 96:43:c4:2e:73:68 [ffffuerthVPN]: 96:43:c4:2e:73:68 (255)<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
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:<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
Hier spendieren wir einen Eintrag, der fastd mit 10 Sekunden Verzögerung bei jedem Systemstart mitstartet:<br />
<pre><br />
# launch fastd with 10 seconds delay<br />
(sleep 10; sh /etc/fastd/fff_beispiel_fastd.sh) &<br />
</pre><br />
<br />
'''Zusätzlich''' muss ein Cronjob angelegt werden, der das Skript z.B. alle 10 Minuten ausführt:<br />
<code><br />
crontab -e<br />
</code><br />
<br />
Nun folgendes eingeben:<br />
<pre><br />
*/10 * * * * sh /etc/fastd/fff_beispiel_fastd.sh<br />
</pre><br />
<br />
und<br />
<br />
<code><br />
/etc/init.d/cron restart<br />
</code><br />
<br><br />
== OpenVPN-Tunnel einrichten ==<br />
Die Einrichtung eines OpenVPN Tunnels kann von Anbieter zu Anbieter variieren. <br />
Im Laufe der Zeit sollte die Dokumentation so um funktionierende Konfigurationen verschiedener Anbieter erweitert werden.<br />
<br><br />
=== Mullvad ===<br />
Mullvad liefert in der Datei mullvadconfig.zip, die notwendigen Schlüssel (ca.crt, mullvad.crt, mullvad.key) als auch eine Konfigurationsdatei (mullvad_linux.conf) mit, die später angepasst werden muss.<br />
<br />
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:<br />
<br />
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.<br />
<br />
Als unverbindliche Richtschnur für Linux:<br />
<code><br />
scp mullvadconfig.zip root@<ipv4 des Gateways>:/root<br />
</code><br />
<br />
Danach loggen wir uns auf dem Gateway ein und entpacken die Datei (nicht vergessen unzip zu installieren):<br />
<code><br />
ssh root@<ipv4 des Gateways><br />
<br />
unzip mullvadconfig.zip<br />
<br />
cd <Kundennummernverzeichnis><br />
<br />
cp * /etc/openvpn<br />
</code><br />
<br />
''/etc/openvpn/'' sollte mit dem Inhalt des entpackten mullvadconfig.zip Archivs dann so aussehen:<br />
<pre><br />
ca.crt crl.pem mullvad.crt mullvad.key mullvad_linux.conf mullvad-up mullvad_windows.conf.ovpn <br />
</pre><br />
<br />
'''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.<br />
<br />
Wir legen ein benutzerspezifisches start-up Script namens mullvad-up an:<br />
<code><br />
vi /etc/openvpn/mullvad-up<br />
</code><br />
<br />
und füllen sie mit folgendem Inhalt:<br />
<pre><br />
#!/bin/bash<br />
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE<br />
</pre><br />
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.<br />
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.<br />
<br />
Das Skript mullvad-up muss ferner ausführbar sein:<br />
<code><br />
chmod +x /etc/openvpn/mullvad-up<br />
</code><br />
<br />
Dieses spezifische Routing muss zwingend in mullvad_linux.conf eingepflegt werden:<br />
<code><br />
vi /etc/openvpn/mullvad_linux.conf<br />
</code><br />
<br />
und hier die Konfiguration entsprechend geändert werden:<br />
<pre><br />
.<br />
.<br />
.<br />
# Allow calling of built-in executables and user-defined scripts.<br />
script-security 2<br />
<br />
# Parses DHCP options from openvpn to update resolv.conf<br />
#up /etc/openvpn/update-resolv-conf<br />
#down /etc/openvpn/update-resolv-conf<br />
<br />
# Enable Freifunk specific Routing<br />
route-noexec<br />
route-delay 3<br />
route-up /etc/openvpn/mullvad-up<br />
.<br />
.<br />
.<br />
</pre><br />
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.<br />
<br />
Wer möchte, kann in mullvad_linux.conf auch Länder definieren, über die der VPN Traffic laufen soll (Ein- /Auskommentieren).<br />
<br />
Der openvpn Tunnel kann nun testweise gestartet werden:<br />
<code><br />
cd /etc/openvpn<br />
<br />
/usr/sbin/openvpn mullvad_linux.conf &<br />
</code><br />
<br />
und sollte exemplarisch und im Auszug folgendes zurück liefern:<br />
<pre><br />
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<br />
Sun Sep 6 12:45:20 2015 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08<br />
Sun Sep 6 12:45:20 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts<br />
.<br />
.<br />
.<br />
Sun Sep 6 12:45:23 2015 /sbin/ip link set dev tun0 up mtu 1500<br />
Sun Sep 6 12:45:23 2015 /sbin/ip addr add dev tun0 10.114.0.45/16 broadcast 10.114.255.255<br />
Sun Sep 6 12:45:23 2015 /sbin/ip -6 addr add fdef:e287:a479:72::102b/112 dev tun0<br />
Sun Sep 6 12:45:23 2015 /etc/openvpn/mullvad-up tun0 1500 1558 10.114.0.45 255.255.0.0 init<br />
Sun Sep 6 12:45:23 2015 Initialization Sequence Completed<br />
</pre><br />
Wichtig ist hierbei, dass in der vorletztes Zeile unser Freifunk-spezifisches Routing durchgeführt wird.<br />
<br />
Das VPN-Gateway sollte nun als Default Route in der fff-Routingtabelle auftauchen:<br />
<code><br />
ip route show table fff | grep default<br />
</code><br />
<br />
Exemplarisch wäre eine Ausgabe für das Tunnel-Device tun0 und dem VPN-Gateway 10.114.0.1:<br />
<pre><br />
default via 10.114.0.1 dev tun0<br />
</pre><br />
<br />
Auch ein ifconfig Eintrag für das Tunnel Device...<br />
<code><br />
ifconfig<br />
</code><br />
<br />
...sollte jetzt existieren (Exemplarisch und im Auszug):<br />
<pre><br />
.<br />
.<br />
.<br />
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 <br />
inet addr:10.114.0.76 P-t-P:10.114.0.76 Mask:255.255.0.0<br />
inet6 addr: fdad:bdef:735d:72::104a/112 Scope:Global<br />
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1<br />
RX packets:1012476 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:640206 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:100 <br />
RX bytes:1250196616 (1.1 GiB) TX bytes:84979294 (81.0 MiB)<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
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:<br />
<code><br />
vi /etc/rc.local <br />
</code><br />
<br />
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:<br />
<pre><br />
# launch vpn with 5 seconds delay<br />
(sleep 5; /usr/sbin/openvpn /etc/openvpn/mullvad_linux.conf >> /var/log/mullvad_vpn.log &) &<br />
</pre><br />
<br><br />
<br />
=== NordVPN ===<br />
NordVPN liefert die Datei config.zip mit, die für jeden verwendbaren VPN-Server eine seperate Konfigurationsdatei enthält.<br />
<br />
'''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.<br />
<br />
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.<br />
<br />
Als unverbindliche Richtschnur für Linux:<br />
<code><br />
scp config.zip root@<ipv4 des Gateways>:/root<br />
</code><br />
<br />
Und entpacken diese auf dem Gateway:<br />
<code><br />
cd ~<br />
<br />
mkdir nordvpn-configs<br />
<br />
mv config.zip nordvpn-configs<br />
<br />
cd nordvpn-configs<br />
<br />
unzip config.zip<br />
</code><br />
<br />
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.<br />
<br />
Im Beispiel nehmen wir se1.nordvpn.com.udp1194.ovpn und passen Sie zunächst Freifunk-spezifisch an (siehe Aussperr-Hinweis oben):<br />
<br />
<code><br />
vi se1.nordvpn.com.udp1194.ovpn<br />
</code><br />
<br />
Ä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:<br />
<pre><br />
.<br />
.<br />
.<br />
# Provide Username and Password<br />
auth-user-pass /etc/openvpn/nordvpn-pw<br />
.<br />
.<br />
.<br />
# Allow calling of built-in executables and user-defined scripts.<br />
script-security 2<br />
<br />
# Enable Freifunk specific Routing<br />
route-noexec<br />
route-delay 3<br />
route-up /etc/openvpn/nordvpn-up<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
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:<br />
<code><br />
cp se1.nordvpn.com.udp1194.ovpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf<br />
</code><br />
<br />
Hier legen wir noch unser Freifunk Startskript und unsere Password Datei an und machen das Skript ausführbar:<br />
<code><br />
touch /etc/openvpn/nordvpn-up<br />
<br />
touch /etc/openvpn/nordvpn-pw<br />
<br />
chmod +x /etc/openvpn/nordvpn-up<br />
</code><br />
<br />
Man öffnet nordvpn-up...<br />
<code><br />
vi /etc/openvpn/nordvpn-up<br />
</code><br />
<br />
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):<br />
<pre><br />
#!/bin/bash<br />
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE<br />
</pre><br />
<br />
Nun öffnet man nordvpn-pw:<br />
<code><br />
vi /etc/openvpn/nordvpn-pw<br />
</code><br />
<br />
Und legt in der ersten Zeile der Datei seinen NordVPN Usernamen und in der zweiten Zeile sein NordVPN Passwort ab:<br />
<pre><br />
(Username bei NordVPN)<br />
(Password bei NordVPN)<br />
</pre><br />
<br />
Der Tunnel kann nun testweise gestartet werden (hier im Beispiel mit der Konfigurationsdatei se1.nordvpn.com.udp1194.ovpn)<br />
<code><br />
openvpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf &<br />
</code><br />
<br />
Und sollte aufgebaut werden:<br />
<pre><br />
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<br />
.<br />
.<br />
.<br />
Sun Sep 27 09:07:15 2015 /sbin/ip link set dev tun0 up mtu 1500<br />
Sun Sep 27 09:07:15 2015 /sbin/ip addr add dev tun0 local 10.8.8.226 peer 10.8.8.225<br />
Sun Sep 27 09:07:18 2015 Initialization Sequence Completed<br />
</pre><br />
<br />
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:<br />
<code><br />
vi /etc/rc.local <br />
</code><br />
<br />
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:<br />
<pre><br />
# launch vpn with 5 seconds delay<br />
(sleep 5; cd /etc/openvpn ; /usr/sbin/openvpn se1.nordvpn.com.udp1194.ovpn.conf >> /var/log/nordvpn.log &) &<br />
</pre><br />
Die Beispiel-Konfigurationsdatei (se1.nordvpn.com.udp1194.ovpn.conf) muss entsprechend angepasst werden.<br />
<br><br />
== DNS Server ==<br />
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.<br />
<br />
----<br />
<br />
'''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.'''<br />
<br />
----<br />
<br />
Hierfür editieren wir die Datei named.conf.options...<br />
<code><br />
vi /etc/bind/named.conf.options<br />
</code><br />
<br />
...und tragen die DNS Server, die wir anfragen wollen, wenn wir die Information nicht selber haben, als forwarders ein:<br />
<pre><br />
.<br />
.<br />
.<br />
forwarders {<br />
10.50.32.1;<br />
10.50.32.2;<br />
8.8.8.8;<br />
};<br />
allow-query { <br />
127.0.0.1/8; <br />
10.0.0.0/8; <br />
};<br />
.<br />
.<br />
. <br />
</pre><br />
In diesem Fall werden die Freifunk Gateways ro1 (10.50.32.1) und fff-nue1 (10.50.32.2) der Fürther Hood als auch Google DNS (8.8.8.8) als Forwarders definiert. Für andere Hoods muss die lokale Adresse der Freifunk DNS Server unter [[Portal:Netz]] ermittelt werden (z.B. 10.50.48.1 für ro1 in der Ansbacher Hood).<br />
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".<br />
<br />
Neustart des DNS-Servers mit der neuen Konfiguration:<br />
<code><br />
/etc/init.d/bind9 restart<br />
</code><br />
<br />
Testen können wir, indem wir vom DNS Server des Gateways (localhost/127.0.0.1) eine DNS-Auflösung abfragen. <br />
<br />
Ein DNS Resolve für freifunk-franken.de ...<br />
<code><br />
dig @127.0.0.1 freifunk-franken.de<br />
</code><br />
<br />
...sollte von uns selber (Server localhost; 127.0.0.1) beantwortet werden:<br />
<pre><br />
;; global options: +cmd<br />
<br />
;; Got answer:<br />
<br />
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5819<br />
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1 <br />
;; OPT PSEUDOSECTION:<br />
; EDNS: version: 0, flags:; udp: 4096<br />
<br />
;; QUESTION SECTION:<br />
;freifunk-franken.de. IN A<br />
;; ANSWER SECTION:<br />
freifunk-franken.de. 3599 IN A 31.172.113.113 <br />
.<br />
. <br />
.<br />
;; Query time: 117 msec<br />
;; SERVER: 127.0.0.1#53(127.0.0.1)<br />
;; WHEN: Tue Sep 08 14:16:32 EEST 2015<br />
;; MSG SIZE rcvd: 275<br />
</pre><br />
<br><br />
<br />
== B.A.T.M.A.N Gateway Selection ==<br />
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.<br />
<br />
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:<br />
* Bandbreite der Netzanbindung (z.B. 100 Mbit/sec, gesplittet in 50 Mbit/sec up/down)<br />
* 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)<br />
* Erfahrungswerten / eigenes Ermessen<br />
* Bandbreite, bei dem der Gateway Prozessor ausgelastet ist<br />
<br />
Eventuell muss zuerst bc nachinstalliert werden, falls nicht vorhanden:<br />
<code><br />
apt-get install bc<br />
</code><br />
<br />
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.<br />
<br />
Importieren des Skripts aus einer Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/dyn_announce_gw_bw.sh -P /usr/local/bin/<br />
</code><br />
<br />
Alternativ kann das Skript auch als leere Datei erstellt werden:<br />
<code><br />
touch /usr/local/bin/dyn_announce_gw_bw.sh<br />
</code><br />
<br />
Wir machen das Skript ausführbar und öffnen die Datei:<br />
<code><br />
chmod +x /usr/local/bin/dyn_announce_gw_bw.sh<br />
<br />
vi /usr/local/bin/dyn_announce_gw_bw.sh<br />
</code><br />
<br />
Und Füllen dieses mit Inhalt oder editieren den importierten Inhalt:<br />
<pre><br />
#!/bin/bash<br />
gwsel_lockfile="/tmp/gwsel_lockfile" # lockfile to allow for low bandwidth settings <br />
<br />
if [ -z "$1" ]; then<br />
echo<br />
echo "usage: $0 <network-interface> <update_interval [sec]> <total BW up [Mbit/sec]> <total BW down [Mbit/sec]>"<br />
echo<br />
echo "e.g. $0 eth0 60 10 10"<br />
echo<br />
exit<br />
fi<br />
<br />
while true<br />
do<br />
if [ ! -e ${gwsel_lockfile} ]; then # lockfile not present<br />
# Bandwidth currently used (time averaged)<br />
R1=$(cat "/sys/class/net/$1/statistics/rx_bytes")<br />
T1=$(cat "/sys/class/net/$1/statistics/tx_bytes")<br />
sleep "$2"<br />
R2=$(cat "/sys/class/net/$1/statistics/rx_bytes")<br />
T2=$(cat "/sys/class/net/$1/statistics/tx_bytes")<br />
TkbitPS=$(echo "scale=0; ($T2 - $T1) / 1024 * 8 / $2" | bc -l)<br />
RkbitPS=$(echo "scale=0; ($R2 - $R1) / 1024 * 8 / $2" | bc -l)<br />
# echo "BW used -- up $1: $TkbitPS kBit/s; down $1: $RkbitPS kBit/s"<br />
<br />
# Remaining bandwidth available; cut-off negative values<br />
Tavail_kbitPS=$(echo "scale=0; if (($3 * 1024 - $TkbitPS) >0) ($3 * 1024 - $TkbitPS) else 0" | bc -l)<br />
Ravail_kbitPS=$(echo "scale=0; if (($4 * 1024 - $RkbitPS) >0) ($4 * 1024 - $RkbitPS) else 0" | bc -l)<br />
# echo "BW available -- up $1: $Tavail_kbitPS kBit/s; down $1: $Ravail_kbitPS kBit/s"<br />
else # lockfile present<br />
Tavail_kbitPS=0<br />
Ravail_kbitPS=0<br />
sleep "$2"<br />
fi<br />
<br />
for bat in /sys/class/net/bat*; do<br />
iface=${bat##*/}<br />
batctl -m $iface gw_mode server "${Ravail_kbitPS}kbit/${Tavail_kbitPS}kbit" <br />
done<br />
done<br />
</pre><br />
<br />
Das Skript übernimmt als Parameter:<br />
* Netzwerkinterface, das es zu überwachen gilt (i.d.R. eth0)<br />
* 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)<br />
* Upload Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)<br />
* Download Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)<br />
<br />
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 olsr Defaultroute mit geringer Bandbreite verfügbar ist.<br />
<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.:<br />
<code><br />
/usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10<br />
</code><br />
<br />
Um die Gateway Selection beim Systemsstart zu aktivieren, können wir das Skript z.B. in rc.local aufrufen:<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
um dort, leicht zeitverzögert, o.a. Befehl einzupflegen, wobei die Parametrisierung noch Gateway-spezifisch angepasst werden muss:<br />
<pre><br />
.<br />
.<br />
.<br />
#enable batman GW selection with 15 seconds delay<br />
(sleep 15; /usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10) &<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
ACHTUNG! Bei mehreren bat Interfaces (weil man in mehreren Hoods Gateway ist) muss diese Einstellung für jedes Gateway gesetzt werden, hier muss das Script unbedingt überarbeitet werden!<br />
<br />
<pre><br />
batctl -m $batX gw_mode xxmbit/xxmbit<br />
</pre><br />
<br />
und dies für jedes batX Interface. Das Script muss daraufhin noch angepasst werden.<br />
<br />
<br />
auf den Routern kann der vorselektierte Gateway mit <br />
<br />
<code><br />
batctl gwl<br />
</code><br />
<br />
angeguckt werden. Ich vermute das der Gateway mit den Pfeil vorne der vorselektierte Gateway ist, allerdings machen erste beobachtete Daten bisher in meinen Augen noch keinen wirklichen Sinn.<br />
<br><br />
<br />
== DHCP Server ==<br />
Die DHCP Konfiguration kann schon mal vorbereitet werden, sollte aber erst mit als letzter Schritt scharf geschaltet werden. Ein DHCP-Server, der Clients nicht funktionierende DNS-Server oder ein nicht funktionierendes Gateway mitteilt, sperrt diese aus dem Freifunk Netz aus.<br />
<br />
In isc-dhcp-server definieren wir ...<br />
<code><br />
vi /etc/default/isc-dhcp-server<br />
</code><br />
<br />
... das der DHCP Server für das B.A.T.M.A.N Device Anfragen beantworten soll:<br />
<pre><br />
.<br />
.<br />
<br />
INTERFACES="bat0"<br />
.<br />
.<br />
</pre><br />
<br />
Nachfolge Konfiguration wird in auskommentierter Form vorbereitet und sollte erst im letzten Schritt durch Einkommentieren und durch einen Neustart des DHCP Servers...<br />
<code><br />
/etc/init.d/isc-dhcp-server restart<br />
</code><br />
...aktiviert werden.<br />
<br />
Die Konfiguration wird in dhcpd.conf vorgenommen:<br />
<code><br />
vi /etc/dhcp/dhcpd.conf<br />
</code><br />
<br />
und folgender Konfigurationsblock zunächst auskommentiert eingefügt, wobei Gateway und Hood spezifische Änderungen noch eingepflegt werden müssen:<br />
<pre><br />
.<br />
.<br />
.<br />
### Freifunk Franken<br />
#option domain-name "fff.community";<br />
#option domain-name-servers 10.50.16.1;<br />
#authoritative;<br />
### Fuerth<br />
#subnet 10.50.32.0 netmask 255.255.248.0 { # Netzwerk und Netzmaske der Fuerther Hood<br />
# range 10.50.38.0 10.50.39.254; # IP-Range die der DHCP-Server innerhalb der Fuerther Hood verwaltet <br />
# option routers 10.50.32.5; # Default-Gateway, dass Clients mitgeteilt wird <br />
# option domain-name-servers 10.50.32.5, 10.50.32.1; # Name-Server, die Clients mitgeteilt werden<br />
#}<br />
</pre><br />
<br />
Netzwerk und Netzmaske müssen derjenigen der Hood des Gateways entsprechen. Im Beispiel ist dies Fürth, für z.B. Hassberge hieße der Eintrag "subnet 10.50.56.0 netmask 255.255.252.0".<br />
<br />
Der IP-Bereich (Range), die der DHCP-Server in der Hood verwaltet, wurde zuvor unter [[Portal:Netz]] reserviert.<br />
<br />
Unter Routers wird den Clients das Default-Gateway mitgeteilt: Das Gateway, über das Clients das Internet oder eine andere Hood erreichen. In unserem Beispiel routet das aufgesetzte Gateway selber via VPN ins Internet oder via olsr (später) in andere Hoods. Als Default-Gateway wird also die eigene statische IP des Gateways, aus der eigenen Hood, die in [[Portal:Netz]] reserviert wurde, verwendet.<br />
<br />
Ähnlich verhält es sich mit den Nameservern: Auf unserem Gateway wurde ein DNS Server eingerichtet, also kann der domain-name-server unser eigenes Gateway, mit der reservierten statische IP aus der Hood, wie in [[Portal:Netz]], sein. Als Backup empfiehlt sich ein weiterer DNS-Server aus der Hood, in unserem Beispiel ro1 in der Fürther.<br />
<br><br />
<br />
== GRE-Tunnel zu anderen Gateways ==<br />
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]].<br />
<br />
Der GRE-Tunnel wird in /etc/network/interfaces...<br />
<code><br />
vi /etc/network/interfaces<br />
</code><br />
<br />
...mit folgenden noch auf das Gateway anzupassenden Einträgen deklariert:<br />
<pre><br />
auto <tunnel><br />
iface <tunnel> inet static<br />
address <Eigene IPv4 (Freifunk Netz)><br />
pre-up ip -4 tunnel add $IFACE mode gre local <Eigene IPv4 (Internet)> remote <IPv4 des Tunnelpartners (Internet)> ttl 255<br />
#pre-up ip -6 tunnel add $IFACE mode ip6gre local <Eigene IPv6 (Internet)> remote <IPv6 des Tunnelpartners (Internet)> ttl 255<br />
<br />
up ifconfig $IFACE multicast<br />
pointopoint <IPv4 des Tunnelpartners (Freifunk Netz)><br />
post-up iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu<br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.50.0.0/16 table fff<br />
post-up ip rule add to 10.50.0.0/16 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ip rule del from 10.50.0.0/16 table fff<br />
post-down ip rule del to 10.50.0.0/16 table fff<br />
post-down iptables -t mangle -D POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu<br />
post-down iptunnel del $IFACE<br />
</pre><br />
<br />
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.<br />
<br />
'''Beispiel:''' <br />
Um als fff-nue1 einen Tunnel zu ro1 aufzubauen, können die IP-Adressen wie folgt gewählt werden:<br />
<pre><br />
<tunnel> ro1<br />
<Eigene IPv4 (Freifunk Netz)> fff-nue1 10.50.252.1<br />
<IPv4 des Tunnelpartners (Freifunk Netz)> ro1 10.50.252.0<br />
<Eigene IPv4 (Internet)> fff-nue1 31.172.33.99<br />
<IPv4 des Tunnelpartners (Internet)> ro1 176.126.221.7<br />
</pre><br />
<br />
In der Partnerkonfiguration für ro1 werden die Rollen entsprechend vertauscht:<br />
<pre><br />
<tunnel> fff-nue1<br />
<Eigene IPv4 (Freifunk Netz)> ro1 10.50.252.0<br />
<IPv4 des Tunnelpartners (Freifunk Netz)> fff-nue1 10.50.252.1<br />
<Eigene IPv4 (Internet)> ro1 176.126.221.7<br />
<IPv4 des Tunnelpartners (Internet)> fff-nue1 31.172.33.99 <br />
</pre><br />
<br />
Der Tunnel kann über den Aufruf von<br />
<code><br />
ifup <tunnel><br />
</code><br />
...aufgebaut werden, wobei <tunnel> der Name des GRE-Interfaces ist (im Beispiel ro1)<br />
<br />
Nach Aufruf von ifconfig..<br />
<code><br />
ifconfig <br />
</code><br />
sollten wir einen Eintrag für den Tunnel (in diesem Beispiel ro1) vorfinden:<br />
<pre><br />
.<br />
.<br />
.<br />
ro1 Link encap:UNSPEC HWaddr B0-7B-1C-73-30-30-3A-35-00-00-00-00-00-00-00-00 <br />
inet addr:10.50.252.1 P-t-P:10.50.252.0 Mask:255.255.255.255<br />
inet6 addr: fe80::200:5efe:b07b:1c73/64 Scope:Link<br />
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1476 Metric:1<br />
RX packets:160913 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:146654 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0 <br />
RX bytes:66984353 (63.8 MiB) TX bytes:10675001 (10.1 MiB)<br />
.<br />
.<br />
.<br />
</pre><br />
<br><br />
== OLSR ==<br />
=== Basiskonfiguration ===<br />
Mittels OLSR können die Gateways selbstständig Routinginformationen austauschen. Ähnlich wie B.A.T.M.A.N einzelne Router innerhalb einer Hood vermesht (Level 2 Netz), handelt es sich bei olsr um ein mesh zwischen den Gateways (Level 3). Es ermöglicht ein Freifunk Franken internes Routing: z.B. kann eine beliebige IPv4 aus der Nürnberger Hood aus der Fürth Hood heraus erreicht werden.<br />
<br />
Vorlagen können unter Sicherung der Originaldateien wie folgt importiert werden:<br />
<code><br />
mv /etc/default/olsrd /etc/default/olsrd.orig<br />
<br />
mv /etc/olsrd/olsrd.conf /etc/olsrd/olsrd.conf.orig<br />
<br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd -P /etc/default/<br />
<br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd.conf -P /etc/olsrd/<br />
</code><br />
<br />
Zunächst zeigen wir die Interfaces an, unter dem wir olsr Routing Informationen austauschen:<br />
<code><br />
vi /etc/default/olsrd<br />
</code><br />
<br />
Im Beispiel wird über die 2 GRE-Tunnel nue1 und ro1 ausgetauscht, dies muss entsprechend der GRE-Tunnel Konfiguration angepasst werden: <br />
<pre><br />
.<br />
.<br />
#<br />
# Uncomment the next line run olsrd automatically at startup<br />
#<br />
START_OLSRD="YES"<br />
<br />
#<br />
# Uncomment the next line to force-configure the wifi interface to be setup<br />
# for ad-hoc mode using the /usr/sbin/olsrd-adhoc-setup script whenever olsrd<br />
# is started.<br />
#<br />
SETUP_ADHOC="NO"<br />
.<br />
.<br />
.<br />
#<br />
# Specify the network interfaces that olsrd will run on, this will most likely<br />
# be your wifi interface.<br />
#<br />
MESH_IF="nue1 ro1" <br />
.<br />
.<br />
</pre><br />
<br />
<br />
Weiter wird dann hier ...<br />
<code><br />
vi /etc/olsrd/olsrd.conf<br />
</code><br />
... konfiguriert. <br />
Da unser Beispiel-Gateway ins Netz der Fürther Hood eingebunden ist, teilen wir dies andern Gateways über den Eintrag 10.50.32.0/21 mit:<br />
<pre><br />
.<br />
.<br />
.<br />
# HNA IPv4 routes<br />
# syntax: netaddr netmask<br />
# Example Internet gateway:<br />
# 0.0.0.0 0.0.0.0<br />
<br />
Hna4<br />
{<br />
# Internet gateway:<br />
# 0.0.0.0 0.0.0.0<br />
# more entries can be added:<br />
# 192.168.1.0 255.255.255.0<br />
10.50.32.0/21<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Hier wird das olsr Webinterface auf port 8080 konfiguriert:<br />
<br />
<pre><br />
.<br />
.<br />
.<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
# defaults to 1978<br />
PlParam "Port" "8080"<br />
# if you dont set these, the default is to listen only on the loopback device<br />
#PlParam "Host" "80.23.53.22"<br />
#PlParam "Net" "10.0.0.0 255.0.0.0"<br />
PlParam "Net" "0.0.0.0 0.0.0.0"<br />
#PlParam "Host" "127.0.0.1"<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Ferner wird der VPN-Tunnel (hier tun0) per persönlich angepasstem ping Kommando auf sein Funktion hin überwacht. Sollte der VPN-Tunnel ausfallen, ermöglicht olsr im Zusammenspiel mit der Routing Priorisierung (s.u) und der OpenVPN Start-/Stop Automatik (s.u.) ein automatisches Re-Routing:<br />
<pre><br />
.<br />
.<br />
.<br />
LoadPlugin "olsrd_dyn_gw.so.0.5"<br />
{<br />
# Here parameters are set to be sent to the<br />
# plugin. Theese are on the form "key" "value".<br />
# Parameters ofcause, differs from plugin to plugin.<br />
# Consult the documentation of your plugin for details.<br />
<br />
# Example: dyn_gw params<br />
<br />
# how often to check for Internet connectivity<br />
# defaults to 5 secs<br />
PlParam "Interval" "5"<br />
<br />
# if one or more IPv4 addresses are given, do a ping on these in<br />
# descending order to validate that there is not only an entry in<br />
# routing table, but also a real internet connection. If any of<br />
# these addresses could be pinged successfully, the test was<br />
# succesful, i.e. if the ping on the 1st address was successful,the<br />
# 2nd won't be pinged<br />
PlParam "Ping" "8.8.8.8"<br />
PlParam "Ping" "82.165.230.17"<br />
PlParam "pingcmd" "ping -c 1 -q -I tun0 %s"<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Folgender Konfigurationsblock muss ans Ende der Konfigurationsdatei angefügt werden. Es ermöglich olsr die Manipulation der fff-Routingtabelle:<br />
<pre><br />
.<br />
.<br />
.<br />
# Specify the proto tag to be used for routes olsr inserts into kernel<br />
# currently only implemented for linux<br />
# valid values under linux are 1 .. 254<br />
# 1 gets remapped by olsrd to 0 UNSPECIFIED (1 is reserved for ICMP redirects)<br />
# 2 KERNEL routes (not very wise to use)<br />
# 3 BOOT (should in fact not be used by routing daemons)<br />
# 4 STATIC<br />
# 8 .. 15 various routing daemons (gated, zebra, bird, & co)<br />
# (defaults to 0 which gets replaced by an OS-specific default value<br />
# under linux 3 (BOOT) (for backward compatibility)<br />
#<br />
RtProto 8<br />
#<br />
# Specifies the routing Table olsr uses<br />
# RtTable is for host routes, RtTableDefault for the route to the default<br />
# internet gateway (2 in case of IPv6+NIIT) and RtTableTunnel is for<br />
# routes to the ipip tunnels, valid values are 1 to 254<br />
# There is a special parameter "auto" (choose default below)<br />
# (with smartgw: default is 254/223/224)<br />
# (without smartgw: default is 254/254/254, linux main table)<br />
#<br />
RtTable 10<br />
RtTableDefault 10<br />
RtTableTunnel 10<br />
#<br />
# Specifies the policy rule priorities for the three routing tables and<br />
# a special rule for smartgateway routing (see README-Olsr-Extensions)<br />
# Priorities can only be set if three different routing tables are set.<br />
# if set the values must obey to condition<br />
# RtTablePriority < RtTableDefaultOlsrPriority<br />
# < RtTableTunnelPriority < RtTableDefaultPriority.<br />
# There are two special parameters, "auto" (choose fitting to SmartGW<br />
# mode) and "none" (do not set policy rule)<br />
# (with smartgw: default is none/32776/32776/32796)<br />
# (without smartgw: default is none/none/none/none)<br />
#<br />
# RtTablePriority auto<br />
# RtTableDefaultOlsrPriority auto<br />
# RtTableTunnelPriority auto<br />
# RtTableDefaultPriority auto<br />
</pre><br />
<br />
<br />
Das Freifunk Franken intere Routing kann nun getestet werden.<br />
<br />
Zunächst einmal starten wir olsr neu:<br />
<code><br />
/etc/init.d/olsrd restart<br />
</code><br />
<br />
<br />
Die Routinginformationen des olsr-meshes sollten in der fff-Routingtabelle auftauchen:<br />
<code><br />
ip route show table fff<br />
</code><br />
<br />
Exemplarischer Auszug:<br />
<pre><br />
.<br />
.<br />
.<br />
10.50.32.1 via 10.50.32.1 dev ro1 proto gated metric 2 onlink <br />
10.50.32.2 via 10.50.32.2 dev nue1 proto gated metric 2 onlink <br />
10.50.40.0/21 via 10.50.32.1 dev ro1 proto gated metric 2 onlink <br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Eine IP4 aus der Nürnberger Hood (10.50.40.0/21) sollte z.B. von Fürth aus (10.50.32.0/21) erreichbar sein:<br />
<br />
<code><br />
ping 10.50.40.3<br />
</code><br />
<br />
Antwort:<br />
<pre><br />
PING 10.50.40.3 (10.50.40.3) 56(84) bytes of data.<br />
64 bytes from 10.50.40.3: icmp_seq=1 ttl=63 time=42.2 ms<br />
64 bytes from 10.50.40.3: icmp_seq=2 ttl=63 time=42.7 ms<br />
^C<br />
--- 10.50.40.3 ping statistics ---<br />
2 packets transmitted, 2 received, 0% packet loss, time 1000ms<br />
rtt min/avg/max/mdev = 42.279/42.516/42.753/0.237 ms<br />
</pre><br />
<br><br />
=== OpenVPN Start/Stop Automatik ===<br />
OLSR testet mit dem Dynamic Gateway Plugin, ob die Default Route über den OpenVPN Tunnel noch funktioniert, indem regelmässig teilweise mehrere verschiedene Ziele über den Tunnel angepingt werden. Sollte der OpenVPN Tunnel nicht mehr funktionieren, baut OLSR eine neue Default-Route zu einem anderem Gateway auf, über das dann der Internet-Traffic läuft. Beide Default-Routen, die über den OpenVPN Tunnel und die von OLSR, existieren parallel, wobei zunächst weiterhin die OpenVPN Verbindung verwendet wird.<br />
<br />
Da die OpenVPN Verbindung ausgefallen ist, aber trotzdem noch als bevorzugte Default-Route eingetragen ist, ist die Internetanbindung bis die Störung VPN-Server seitig behoben ist, trotzdem nicht verfügbar. <br />
<br />
Für diesen Anwendungsfall wird ein Skript vorgeschlagen, dass die Funktion des OpenVPN Tunnels überwacht und den Tunnel (und die OpenVPN Default-Route) bei Nicht-Funktion abbaut. Um die Funktion zu überprüfen werden in regelmässigen Abständen 2 verschiedene Ziele über den Tunnel angepingt. Scheitert dies, wird der Tunnel für einen gewissen Zeitraum abgebaut, in dem dann stattdessen das OLSR Dynamic Gateway Plugin das Routing übernimmt. Danach wird die Verbindung wieder aufgebaut. Anschliessend wird überprüft, ob der OpenVPN-Tunnel wieder funktioniert. Tut er es nicht, wird er wieder abbgebaut, funktioniert er, bleibt er bis zur Detektion der nächsten Störung als Internetanbindung erhalten.<br />
<br />
Man importiert die Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/auto_start-stop_ovpn.sh -P /usr/local/bin/<br />
</code><br />
<br />
Alternativ kann man statt der Vorlage auch eine leere Datei anlegen:<br />
<code><br />
touch /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
Man macht das Skript ausführbar:<br />
<code><br />
chmod +x /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
<br />
Nun öffnet man die Datei im Editor ...<br />
<code><br />
vi /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
... und füllt sie mit Inhalt oder editiert den importierten Inhalt:<br />
<pre><br />
#!/bin/bash<br />
<br />
IF="tun0" # Interface used for ping<br />
ping1_target="8.8.8.8" # IP no. 1 used for ping<br />
ping2_target="82.165.229.31" # IP no. 2 used for ping<br />
ping_interval="5" # waiting time in-between two pings<br />
switchback_interval="3600" # waiting time for interface to recover before probing again<br />
start_grace="10" # waiting time to allow for tunnel restart<br />
logfile="/dev/null" # logfile for debug<br />
gwsel_lockfile="/tmp/gwsel_lockfile" # lockfile to allow for low bandwidth settings <br />
<br />
openvpn_stop-cmd () { # command used disabling tunnel<br />
#service openvpn stop # ubuntu<br />
/etc/init.d/openvpn stop # debian<br />
#killall openvpn # hardcore<br />
}<br />
<br />
openvpn_start-cmd () { # command used enabling tunnel<br />
#service openvpn start # ubuntu<br />
/etc/init.d/openvpn start # debian<br />
#openvpn /etc/openvpn/*.conf & # hardcore<br />
}<br />
<br />
ping1 () {<br />
echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF" &>> $logfile<br />
ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF &>> $logfile<br />
ping1_ExitCode=$?<br />
echo "$(date): Exit Status: ${ping1_ExitCode}" &>> $logfile<br />
}<br />
<br />
ping2 () {<br />
echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF" &>> $logfile<br />
ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF &>> $logfile<br />
ping2_ExitCode=$?<br />
echo "$(date): Exit Status: ${ping2_ExitCode}" &>> $logfile<br />
}<br />
<br />
<br />
while true<br />
do<br />
# wait for interface build-up, if interface not present<br />
if [ ! -h "/sys/class/net/$IF" ]; then<br />
echo "$(date): Interface $IF not detected. Waiting ${start_grace} seconds." &>> $logfile<br />
sleep ${start_grace}<br />
fi<br />
<br />
# perform ping<br />
ping1<br />
ping2<br />
<br />
# check if ping successful<br />
if ([[ ${ping1_ExitCode} -eq 0 ]] || [[ ${ping2_ExitCode} -eq 0 ]]); then<br />
sleep ${ping_interval}<br />
else<br />
logger -t "$0" ${ping1_target} and ${ping2_target} not reached via interface $IF.<br />
echo "$(date): ${ping1_target} and ${ping2_target} not reached via interface $IF." &>> $logfile<br />
<br />
if [ -h "/sys/class/net/$IF" ]; then<br />
logger -t "$0" Stopping interface $IF.<br />
echo "$(date): Stopping interface $IF." &>> $logfile<br />
openvpn_stop-cmd &>> $logfile<br />
touch ${gwsel_lockfile} &>> $logfile<br />
fi<br />
<br />
sleep ${switchback_interval}<br />
<br />
if [ ! -h "/sys/class/net/$IF" ]; then<br />
logger -t "$0" Restoring interface $IF to probe for recovery.<br />
echo "$(date): Restoring interface $IF to probe for recovery." &>> $logfile<br />
openvpn_start-cmd &>> $logfile<br />
rm -f ${gwsel_lockfile} &>> $logfile<br />
fi<br />
fi<br />
done<br />
</pre><br />
<br />
Hierbei können im Skript folgende Anpassungen vorgenommen werden:<br />
*openvpn_stop-cmd: Der Befehl, mit dem der OpenVPN Tunnel '''abgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ als Prozess gekillt werden.<br />
*openvpn_start-cmd: Der Befehl, mit dem der OpenVPN tunnel '''aufgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ per openvpn Kommandozeilenaufruf gestartet werden.<br />
*IF: Das OpenVPN Tunnel Device. Normalerweise ist das tun0.<br />
*ping1_target,ping2_target: Die IP-Adressen die über das Tunnel-Interface IF angepingt werden, um den Tunnel auf Funktion zu überprüfen. Vorauswahl: Google DNS und Web.de<br />
*ping_interval: Der zeitliche Anstand zwischen zwei Ping-Versuchen. Vorauswahl: 5 Sekunden.<br />
*switchback_interval: Der Zeitraum, den der Tunnel abgebaut bleibt, sollte er als nicht-funktionierend erkannt worden sein. Es wird ein träges Verhalten empfohlen. Vorauswahl: 3600 Sekunden.<br />
*start_grace: Der Zeitraum, der dem Tunnel zum Starten eingeräumt wird. Die Timer-Funktion macht ferner das Skript gegen Restarts des Tunnels unempfindlich.<br />
*logfile: Für Debug Zwecke kann man detaillierte Ausgaben hier in eine Datei umleiten.<br />
*gwsel_lockfile: Setzt bei Störumschaltung ein Lockfile, dass von dem Skript der Gateway Selection (s.o.) ausgewertet werden kann, um eine kleinere Bandbreite für die Dauer der Störumschaltung zu annoncieren. Das Lockfile wird beim Wiederstart des OpenVPN Tunnels gelöscht.<br />
<br />
Das Skript selber kann manuell ...<br />
<code><br />
auto_start-stop_ovpn.sh &<br />
</code><br />
<br />
...und bei jedem Systemstart mit gestartet werden, indem es z.B. in /etc/rc.local ...<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
...wie folgt eingetragen wird:<br />
<pre><br />
.<br />
.<br />
.<br />
#enable tunnel monitoring with 60 seconds delay<br />
(sleep 60; auto_start-stop_ovpn.sh &) &<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Getestet werden kann das Skript z.B., indem man sich alle Default-Routen der fff-Tabelle anzeigen lässt: <br />
<code><br />
watch "ip route show table fff | grep default"<br />
</code><br />
<br />
und parallel dazu auf einer zweiten Shell das openvpn deaktiviert:<br />
<code><br />
killall openvpn<br />
</code><br />
<br />
Es sollte eine neue Default-Route zu einem anderen Gateway aufgebaut werden, über die der Internet-Traffic dann läuft. Die Route über den OpenVPN Tunnel sollte verschwinden. Nach der eingestellten Zeit wird der OpenVPN Tunnel durch das Skript wieder reaktiviert. Danach existieren beide Default-Routen parallel, bis OLSR seine Route automatisch wieder abbaut. Die OpenVPN Default-Route bleibt und ist wieder aktiv.<br />
<br><br />
<br />
=== Priorisieren von OLSR Routen ===<br />
OLSR erstellt die fff-Routingtabelle selbstständig, indem es die Linkqualität anhand von Algorithmen bewertet. Diese Bewertung ist recht volatil, was dazu führen kann, das die von OLSR ausgesuchte Default-Route häufig wechselt. Für die verbundenen Clients wechselt jedes mal die externe Internet IP mit, je nachdem über welches Gateway OLSR den Internet-Traffic gerade abwirft. Bei IP-Wechsel stoppen z.B. Downloads aus dem Internet, stoppen Videos im Abspielen, werden ssh Verbindungen gekappt.<br />
<br />
Um diese Dynamik nicht allzu schnell zu gestalten, empfiehlt es sich OLSR eine oder zwei Default-Routen mitzuteilen, die bevorzugt verwendet werden. Zusätzlich wird NatThreshold, einen Schwellwert den die neue Default-Route besser sein muss als die alte, bevor gewechselt wird, definiert.<br />
<br />
Dies geschieht über Gewichtungsfaktoren in olsrd.conf:<br />
<br />
<code><br />
vi /etc/olsrd/olsrd.conf<br />
</code><br />
<br />
Routen kann man im Abschnitt InterfaceDefaults priorisieren. <br />
Hier können Gewichtungsfaktoren für die GRE-Tunnel zu anderen Gateways eingeführt werden, mit denen die Link-Qualität beeinflusst werden kann:<br />
<pre><br />
.<br />
.<br />
.<br />
# If a certain route should be preferred<br />
# or ignored by the mesh, the Link Quality<br />
# value of a node can be multiplied with a factor<br />
# entered here. In the example the route<br />
# using 192.168.0.1 would rather be ignored.<br />
# A multiplier of 0.5 will result in a small<br />
# (bad) LinkQuality value and a high (bad)<br />
# ETX value.<br />
<br />
# preferred link<br />
LinkQualityMult <tunnel1_ip> 0.99<br />
<br />
# preferred link<br />
LinkQualityMult <tunnel2_ip> 0.99<br />
<br />
# This multiplier applies to all other nodes<br />
LinkQualityMult default 0.7<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Im Beispiel werden alle Routen herabgestuft (Faktor 0.7), mit der Ausnahme derer die über <tunnel1_ip> oder <tunnel2_ip> laufen (Faktor 0.99). <tunnel_ip1> sind dabei die Point-to-Point Partner IPs der GRE Tunnel der jeweiligen Gateways im Freifunk Netz. Die nicht herabgestuften Routen können analog als priorisiert betrachtet werden. Für eine Priorisierung der Route von nue1 zu ro1 wäre die <tunnel1/2_ip> z.B. die 10.50.252.1 (Vgl. [[Portal:Netz]]).<br />
<br />
NatThreshold wird im Hauptabschnitt von olsrd.conf definiert:<br />
<pre><br />
.<br />
.<br />
# If the NAT-Endpoint (the preferred 0/0 HNA emitting node)<br />
# is to be changed, the ETX value of the current 0/0 is<br />
# multiplied with the NatThreshold value before being<br />
# compared to the new one<br />
# The parameter can be a value between 0.1 and 1.0, but<br />
# should be close to 1.0 if changed.<br />
<br />
NatThreshold 0.7<br />
.<br />
.<br />
</pre><br />
<br />
Im Beispiel muss die Linkqualität der neuen Default-Route um 30% besser bewertet als die aktuelle sein, bevor die Default-Route gewechselt wird.<br />
<br />
Die Änderungen werden nach Neustart von OLSR aktiv:<br />
<code><br />
/etc/init.d/olsrd restart<br />
</code><br />
<br><br />
= Einbringen des Gateways in die Hood / Keyserver =<br />
Abschliessend muss das Gateway im Keyserver als Gateway der entsprechenden Hood eingetragen werden. Hierfür benötigt man einen Keyserver-Administrator => [[Server]].<br />
<br />
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.<br />
<br />
Der DHCP-Server sollte als letzter Schritt aktiviert werden (s.o.)<br />
<br><br />
= Transparent Proxy =<br />
Auf dem Gateway kann (aber muss nicht) ein Proxy-Server installiert werden, der Dateien (z.B. Bilder), die schon mal angefragt wurden, nicht aus dem Internet holt, sondern als "lokal" gespeicherte Datei direkt vom Gateway bereitstellt. Die Clients werden dabei über den Proxy gezwungen, d.h. das Gateway leitet die Anfragen pauschal an den Proxy weiter, welcher entscheidet ob der die Anfrage selber bedient oder Gateway-extern anfragt. <br />
<br />
Die Einrichtung eines Proxys ist '''optional''', d.h. der Proxy ist für die Funktion des Gateways nicht notwendig. Proxy-Server reduzieren Antwortzeiten und Traffic für sich '''häufig''' wiederholende Anfragen (z.B. Spiegel Online, Windows Update).<br />
<br />
'''Hinweis''': <br />
Die Einrichtung eines Proxy ist umstritten, da:<br />
* HTTP-Header, wenn auch in geringem Umfang, verändert werden<br />
* Daten, wenn auch nicht direkt einsehbar, auf dem Gateway gespeichert werden<br />
* Daten nicht unmittelbar von der Originalquelle bezogen werden <br />
* Die Effizienzsteigerung gering ist. Nach Auswertung werden ca. 7% aller unverschlüsselten HTTP-Anfragen von dem Gateway direkt beantwortet. Für diese 7% halbiert sich der benötigte Traffic, wobei ein Großteil aller Webseiten heutzutage verschlüsselt wird und z.Zt. 50% des benötigten Traffics Overhead ist. <br />
* Zusätzliche Ressourcen (RAM, Prozessor) auf dem Gateway benötigt werden <br />
<br />
'''Inkompatiblität''': Die Konfiguration funktioniert z.Zt. nicht im Zusammenspiel mit der "OpenVPN Start/Stop Automatik" und dem automatischen OLSR Re-Routing des Default-Gateways (Dynamic Gateway Plugin).<br />
<br><br />
== Installation ==<br />
Installiert wird der de-facto-Standard squid:<br />
<code><br />
apt-get install squid3<br />
</code><br />
<br />
Für die kommende Konfiguration stoppen wir squid wieder:<br />
<code><br />
/etc/init.d/squid3 stop<br />
</code><br />
<br><br />
== Konfiguration ==<br />
Die mit installiere Konfigurationsdatei squid.conf ist sehr umfangreich und bietet eine gute Dokumentationsbasis, ist damit aber auch etwas unhandlich.<br />
<br />
Aus diesem Grund empfiehlt es sich, die Datei umzubenennen:<br />
<code><br />
mv /etc/squid3/squid.conf /etc/squid3/squid.conf.orig<br />
</code><br />
<br />
Wir importieren die Datei von einer Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/squid.conf -P /etc/squid3/<br />
</code><br />
<br />
Alternativ können wir die Datei auch leer erstellen:<br />
<code><br />
touch /etc/squid3/squid.conf<br />
</code><br />
<br />
Danach öffnen wir die Konfigurationsdatei...<br />
<code><br />
vi /etc/squid3/squid.conf<br />
</code><br />
<br />
...und füllen diese mit Inhalt, der allerdings noch auf das Gateway angepasst werden muss:<br />
<pre> <br />
# cache size in MB / no. of subdirectories / no. of subsubdirectories<br />
cache_dir ufs /var/spool/squid3 100 16 256<br />
<br />
#maximum object size in cache (default: 4 MB)<br />
#maximum_object_size 128 MB<br />
maximum_object_size 4 MB<br />
<br />
# Memory used for caching<br />
cache_mem 32 MB<br />
<br />
# No access log<br />
#access_log /var/log/squid3/access.log combined<br />
access_log none<br />
<br />
# Hostname shown in messages<br />
visible_hostname fff<br />
<br />
# Bind Squid to port ... and configure as transparent proxy <br />
http_port 3128 intercept<br />
# In addition a forward proxy is required<br />
http_port 3129<br />
<br />
refresh_pattern ^ftp: 1440 20% 10080<br />
refresh_pattern ^gopher: 1440 0% 1440<br />
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0<br />
refresh_pattern . 0 20% 4320<br />
<br />
# Allow connects from Freifunk Franken network<br />
acl fff src 10.50.0.0/16 <br />
<br />
# DNS by Freifunk-IP of localhost and Google DNS<br />
dns_nameservers 10.50.32.5 8.8.8.8<br />
<br />
# Bind outgoing address to Freifunk-Server IP to allow for VPN Routing <br />
tcp_outgoing_address 10.50.32.5<br />
udp_outgoing_address 10.50.32.5<br />
<br />
# Privacy options <br />
via off<br />
forwarded_for delete<br />
<br />
# standard http anonymizer<br />
request_header_access From deny all<br />
#request_header_access Referer deny all<br />
#request_header_access User-Agent deny all<br />
<br />
## paranoid http anonymizer<br />
#request_header_access Authorization allow all<br />
#request_header_access Proxy-Authorization allow all<br />
#request_header_access Cache-Control allow all<br />
#request_header_access Content-Length allow all<br />
#request_header_access Content-Type allow all<br />
#request_header_access Date allow all<br />
#request_header_access Host allow all<br />
#request_header_access If-Modified-Since allow all<br />
#request_header_access Pragma allow all<br />
#request_header_access Accept allow all<br />
#request_header_access Accept-Charset allow all<br />
#request_header_access Accept-Encoding allow all<br />
#request_header_access Accept-Language allow all<br />
#request_header_access Connection allow all<br />
#request_header_access All deny all<br />
<br />
# Access controls<br />
acl SSL_ports port 443 # https<br />
acl Safe_ports port 80 # http<br />
acl Safe_ports port 21 # ftp<br />
acl Safe_ports port 443 # https<br />
acl Safe_ports port 70 # gopher<br />
acl Safe_ports port 210 # wais<br />
acl Safe_ports port 1025-65535 # unregistered ports<br />
acl Safe_ports port 280 # http-mgmt<br />
acl Safe_ports port 488 # gss-http<br />
acl Safe_ports port 591 # filemaker<br />
acl Safe_ports port 777 # multiling http<br />
<br />
acl CONNECT method CONNECT<br />
http_access deny !Safe_ports<br />
http_access deny CONNECT !SSL_ports<br />
http_access allow localhost manager<br />
http_access deny manager<br />
http_access allow fff<br />
http_access allow localhost<br />
http_access deny all<br />
</pre><br />
<br />
Hier '''müssen''' angepasst werden:<br />
* cache_dir: Die Gesamtgröße des Caches (hier: 100 MByte) muss so bemessen sein, dass auf der Partition auch bei Maximalgröße des Caches noch Speicher frei bleibt. Squid Standardeinstellung ist 100 MB bei 16 Verzeichnissen und jeweils 256 Unterverzeichnissen. Freier Speicherplatz kann mit "df -h" ermittelt werden.<br />
* dns_nameservers: Hier sollten die '''Freifunk-IPv4''' des Gateways (in diesem Beispiel 10.50.32.5) und eine externe IP (hier Google DNS 8.8.8.8) eingetragen werden. Wichtig ist, '''nicht localhost''' einzutragen, da die Anfrage im Zusammenspiel mit der "outgoing address" (s.u.) über die fff-Routingtabelle laufen muss.<br />
* tcp_outgoing_address und udp_outgoing_address: Diese beide Einträge sind elementar wichtig. Zwar funktioniert der Proxy auch ohne, routet aber nicht über das VPN sondern direkt vom Gateway ins Internet. Damit die fff-Routingtabelle verwendet wird, für die als Default-Gateway eine VPN Verbindung eingerichtet ist, tragen wir hier die Freifunk-IP des Gateways ein (10.50.<irgendwas>). In diesem Beispiel ist die Freifunk-IPv4 des Gateways die 10.50.32.5.<br />
* access_log: Das Access log sollte deaktiviert bleiben (access_log none), da es ein lebendiges Beispiel für Vorratsdatenspeicherung ist und die log-Dateien auch sehr schnell, sehr groß werden.<br />
<br />
Danach erstellen wir die Verzeichnisstruktur des Proxy:<br />
<code><br />
squid3 -z<br />
</code><br />
<br />
Jetzt sind wir fast fertig. Wir starten den Proxy:<br />
<code><br />
/etc/init.d/squid3 start<br />
</code><br />
<br />
Anfragen, die auf Port 80 (http) reinkommen, müssen nun noch auf Port 3128 umgeleitet werden. Auf Port 3128 lauscht unser Proxy, http-Anfragen werden quasi transparent (oder zwangsweise) über den Proxy geleitet :<br />
<code><br />
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
</code><br />
<br />
Damit unsere Portumleitung mit jedem Start von Squid eingerichtet und mit jedem Stopp aufgehoben wird, pflegen wir sie (nicht ganz sauber) im squid start/stop Skript mit ein:<br />
<code><br />
vi /etc/init.d/squid3<br />
</code><br />
<br />
und fügen '''zwei''' iptables Einträge nach dem Start und vor dem Stopp von Squid ein:<br />
<pre><br />
.<br />
.<br />
.<br />
start () {<br />
cache_dir=`find_cache_dir cache_dir`<br />
cache_type=`grepconf cache_dir`<br />
<br />
#<br />
# Create run dir (needed for several workers on SMP)<br />
#<br />
create_run_dir<br />
<br />
#<br />
# Create spool dirs if they don't exist.<br />
#<br />
if test -d "$cache_dir" -a ! -d "$cache_dir/00"<br />
then<br />
log_warning_msg "Creating $DESC cache structure"<br />
$DAEMON -z -f $CONFIG<br />
fi<br />
<br />
umask 027<br />
ulimit -n 65535<br />
cd $cache_dir<br />
start-stop-daemon --quiet --start \<br />
--pidfile $PIDFILE \<br />
--exec $DAEMON -- $SQUID_ARGS < /dev/null<br />
# Use as transparent proxy<br />
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
return $?<br />
}<br />
<br />
stop () {<br />
PID=`cat $PIDFILE 2>/dev/null`<br />
# Use as transparent proxy<br />
iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
start-stop-daemon --stop --quiet --pidfile $PIDFILE --exec $DAEMON <br />
#<br />
# Now we have to wait until squid has _really_ stopped.<br />
#<br />
.<br />
.<br />
.<br />
</pre></div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Freifunk-Gateway_aufsetzen&diff=5361
Freifunk-Gateway aufsetzen
2016-01-23T13:59:22Z
<p>Green: /* OpenVPN Start/Stop Automatik */</p>
<hr />
<div>__TOC__<br />
[[Kategorie:Technik]]<br />
<br />
= Preface =<br />
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").<br />
<br />
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.<br />
<br />
Für Rat und Tat empfiehlt sich die Freifunk Franken Development Mailingliste.<br />
<br><br />
= Vorraussetzungen =<br />
* ssh-Zugang zum Server<br />
* Root Zugriff auf den Server. Entweder man ist "root" (Annahme in diesem Artikel) oder man kann Befehle mit "root-Rechten" durch ein vorgesetztes "sudo" ausführen sowie die Möglichkeit auf dem Server Kernelmodule zu laden (kann nicht jeder VServer!) <br />
* Grundlegende Netzwerkkenntnisse<br />
** IPv4 und Netzmaske<br />
** Devices<br />
** Routing (Default Route, Interfaces, Routing-Table) <br />
* Kentnisse <br />
** im Umgang mit Texteditoren (der im Artikel verwendete Editor kann durch beliebig andere ersetzt werden, z.B. durch "nano")<br />
** im Umgang mit der Linux Shell (z.B. Kommandozeilenparameter, Shell-Scripte, Umleitungen)<br />
** in der (selbständigen Nach-)Installation von (fehlenden) Software-Paketen<br />
** im Kompilieren von Software-Quellen<br />
<br><br />
= Referenzen / Andere Freifunk HowTo's =<br />
* http://wiki.freifunk.net/Freifunk_Hamburg/Gateway <br />
* http://wiki.mag.lab.sh/wiki/Freifunk_Fulda/Gateway<br />
<br><br />
= Anforderungen an Gateways =<br />
Die Anforderungen an das Gateway sind an sich niedrig. Wichtig ist, dass die Möglichkeit besteht, eigene Kernel-Module zu laden und das monatliche Traffic-Kontingent nicht zu niedrig ist. Entsprechend sind OpenVZ, Linux-vServer und ähnliche Containerlösungen nicht geeignet.<br />
<br />
Hardware:<br />
* CPU: 1x (64Bit)<br />
* RAM: 256MB .. 1GB<br />
* HDD: > 5 GB<br />
* NIC: 1x<br />
<br />
Software:<br />
* Debian Jessie (8) 64Bit Kernel <br />
* fastd v17<br />
* openvpn<br />
* B.A.T.M.A.N. adv 2013.4.0<br />
* dhcpd<br />
* olsr<br />
* bind9<br />
<br />
Pauschal gibt es keine Mindestanforderungen für den Trafficverbrauch. Es kommt sehr darauf an, wo der Server eingesetzt wird. <br />
'''Momentan suchen wir aber vor allem Server mit einem kostenlosen Traffic von mindestens 10-20 TB/Monat.'''<br />
<br><br />
== Anonymisierung (Störerhaftung) ==<br />
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.<br />
<br />
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. <br />
<br />
Folgende VPN-Anbieter sind zu diesem Zeitpunkt jedoch empfehlenswert:<br />
<br />
* [https://mullvad.net/en/ Mullvad] (Schweden, Niederlande)<br />
** Bis zu drei gleichzeitige Verbindungen<br />
** Kann man anonym mit Bitcoin bezahlen<br />
** Serverauswahl über die ausgelieferte OpenVPN-Konfiguration<br />
*** Server in den Niederlanden sind abends oft stark ausgelastet<br />
**(Gute Erfahrungen in Lübeck)<br />
<br />
* [https://integrityvpn.com/ Integrity VPN] (Schweden, Port80)<br />
** 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.<br />
**Hat eine überaus seriöse Webseite und eine Ltd. erfunden.™<br />
**Hat schon mal was von IPv6 gehört. Nutzt es zurzeit jedoch nur für SEO.<br />
**Blockiert Port 25 derzeit nicht.<br />
**Ist ein ein neuer Anbieter, der _bisher_ unausgelastet wirkt.<br />
** sind derzeit noch nicht nicht overselled und haben ihren Krams scheinbar halbwegs sauber konfiguriert<br />
<br />
* [https://ipredator.se/ Ipredator] (Schweden, Niederlande, Deutschland)<br />
** (Glänzen nicht durch Kompetenz, da sie lange Zeit nur PPTP angeboten haben)<br />
** Mögen schnelle Reconnects nicht -> manchmal muss man OpenVPN ein paar Stunden deaktivieren, bevor es wieder funktioniert.<br />
** Möchten bald auch IPv6 anbieten.<br />
** Angeblich Reseller von relakks<br />
<br />
Ungetestet:<br />
* [https://www.anonine.com/en Anonine VPN] (Portlane)<br />
* [https://privacy.io/ privacy.io] (Portlane)<br />
* [http://prq.se/?p=tunnel&intl=1 prq.se] (Eigenes Netz, teuer)<br />
* [http://arethusa.su/vpn.html Arethusa VPN] (Loggen in Frankreich, andere Server angeblich nicht)<br />
<br />
Einige Freifunknetze mieten auch VMs in Osteuropa. Da die VMs noch nicht an ihre Grezen stößt könnte man diese auch mitnutzen. Ansprechpartner wäre s0ma.<br />
<br><br />
== Anbindung an andere Netze ==<br />
Es gibt drei relativ relevante Netzwerke bei denen es sich lohnt, das lokale Netz damit zu verbinden:<br />
<br />
* InterCity-VPN zwischen den meisten Freifunknetzen<br />
** BGP<br />
** kleine Übsicht der http://www.ddmesh.de/topology/ic-vpn-verbindungen.html<br />
** Mehr Infos http://wiki.freifunk.net/IC-VPN<br />
<br />
* DN42<br />
** BGP<br />
** Experimentelles Darknet zur Erprobung von Routing-Technologien und so weiter, wird privat betrieben. Viel interessantes Zeugs™<br />
** 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.<br />
<br />
* ChaosVPN<br />
** Tinc<br />
** Relativ großes „Darknet“ zwischen vielen Hackerspaces auf der ganzen Welt.<br />
<br><br />
== vServer-Anbieter die empfehlenswert sind ==<br />
* [https://www.de-punkt.de/vserver.html de-punkt] (Databurg, FFM)<br />
** Schneller Speicher, gut bezahlbar, KVM, nur Traffic-Flat™® das übliche.<br />
* [http://www.hetzner.de/hosting/produktmatrix_vserver/vserver-produktmatrix Hetzner] (Falkenstein)<br />
** Bezahlbar, 6.90€/TB Extratraffic, KVM<br />
** Achtung: Die Netzwerkarte der VM ist aus Kompatibilitätsgründen auf e1000 gesetzt. Diese "Netzwerkkarte" kommt nicht mit den vielen UDP-Paketen von fastd zurecht. Deshalb muss man vor Verwendung als Gateway die Netzwerkkarte auf "virtio" stellen.<br />
* [http://colorhost.de/server/vserver/ colorhost] (über 23media, Global Switch, FFM)<br />
* Untersagt Nutzung für Freifunk (http://colorhost.de/server/vserver/kvm/small/)<br />
** Achtung: Nur Xen oder Xen HVM funktionieren<br />
* [http://www.xirra.net/en/v-server/productmatrix/ xirra] (Core-Backbone, NBG)<br />
** KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.<br />
* [http://buyvm.net/ BuyVM]<br />
** 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.<br />
* [http://webhod.de webhod]<br />
** 9,99 € für die kleinste KVM im Monat[https://www.webhod.de/de/vserver/kvm.html]<br />
<br><br />
== Server-Anbieter die '''nicht''' empfehlenswert sind ==<br />
* [http://www.wrzhost.com/ WRZhost]<br />
** 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.<br />
<br />
* [https://www.netcup.de/ netcup]<br />
** V-Server laufen zwar grundsätzlich gut, allerdings halten sie sich nicht an ihre Versprechungen. Server wurde bereits mehrfach gedrosselt obwohl der Traffic weit unter den versprochenen 80 Mbit/s war (zwischen 30 und 40 Mbit/s). Die Drosselung tritt ohne Vorwarnung in Kraft und man kann seinen Server nicht mehr erreichen. Entdrosselung nur auf Nachfrage und dann auch nur mit einigem hin und her.<br />
<br><br />
= Grundinstallation des Servers =<br />
Vom ausgesuchten Hoster lassen wir uns eine aktuelle Linux-Distribution installieren oder ausliefern, wobei sich die Anleitung auf ein Debian 8 / Jessie bezieht.<br />
<br><br />
== Repositories und Update ==<br />
Als erstes werfen wir einen Blick in...<br />
<br />
<code><br />
vi /etc/apt/sources.list<br />
</code><br />
<br />
...und schauen, inwieweit auf die gleichen Software-Repositories verwiesen wird:<br />
<br />
<pre> <br />
deb http://security.debian.org/ jessie/updates main<br />
deb-src http://security.debian.org/ jessie/updates main<br />
<br />
deb http://ftp.de.debian.org/debian/ jessie main contrib non-free<br />
deb-src http://ftp.de.debian.org/debian/ jessie main contrib non-free<br />
<br />
deb http://ftp.de.debian.org/debian/ jessie-updates main<br />
deb-src http://ftp.de.debian.org/debian/ jessie-updates main<br />
<br />
</pre><br />
<br />
Danach bringen wir das System auf einen aktuellen Stand:<br />
<br />
<code><br />
apt-get update<br />
<br />
apt-get upgrade<br />
</code><br />
<br><br />
== Sicherheit ==<br />
Den SSH-Zugang besser schützen durch:<br />
* Änderung des Ports<br />
* login nur mit key<br />
* Siehe [http://www.thomas-krenn.com/de/wiki/Absicherung_eines_Debian_Servers hier] für genaue Anleitung: <br />
<br />
<code><br />
apt-get install fail2ban<br />
</code><br />
<br />
und [http://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban_absichern einrichten]<br />
<br />
So,nun sollte der Server ausreichend abgesichert sein.<br />
<br><br />
== B.A.T.M.A.N. adv 2013.4.0 Kernel-Modul ==<br />
Batman-Adv aus Jessie ist zu neu. Hier muss manuell das alte B.A.T.M.A.N. advanced 2013.4.0 gebaut werden.<br />
<br />
Hierfür benötigen wir minimal die Paketquellen build-essential, linux-headers-amd64 und git:<br />
<br />
<code><br />
apt-get install build-essential linux-headers-amd64 git gnupg-curl<br />
</code><br />
<br />
Die Softwarequellen müssen heruntergeladen...<br />
<code><br />
cd ~<br />
<br />
git clone https://github.com/freifunk-gluon/batman-adv-legacy<br />
<br />
cd batman-adv-legacy<br />
</code><br />
<br />
... und kompiliert und installiert werden:<br />
<br />
<code><br />
make<br />
<br />
make install<br />
</code><br />
<br />
Hinweis: Sollten noch Paketquellen fehlen, wird dies während des Kompilierens gemeldet. Die Software-Quellen müssen nachinstalliert werden und der letzte Kompilierungs- und Installationsschritt so lange wiederholt werden, bis die Software erfolgreich erstellt wurde.<br />
<br />
Nach erfolgreicher Erstellung kann das B.A.T.M.A.N Kernel Modul per modprobe händisch eingebunden werden:<br />
<br />
<code><br />
modprobe batman-adv<br />
</code><br />
<br />
Es sollte dann im Kernel-log ....<br />
<code><br />
dmesg | grep batman_adv<br />
</code><br />
<br />
... mit einem Eintrag gelistet werden:<br />
<pre><br />
batman_adv: B.A.T.M.A.N. advanced 2013.4.0-21-ga854277-dirty (compatibility version 14) loaded<br />
</pre><br />
<br />
Das Kernelmodul von B.A.T.M.A.N. kann dann bei jedem Neustart des Systems geladen werden, indem in die Datei /etc/modules:<br />
<br />
<code><br />
vi /etc/modules<br />
</code><br />
<br />
..der Eintrag "batman-adv" hinzugefügt wird:<br />
<br />
<pre><br />
batman-adv<br />
</pre><br />
<br><br />
== B.A.T.M.A.N adv 2013.4.0 batctl ==<br />
Gleiches gilt für batctl, ein Kommandozeilenprogramm zur B.A.T.M.A.N Konfiguration. Die alte Version 2013.4.0 muss selber gebaut werden, da die Debian 8 / Jessie Paketquellen zu neu sind.<br />
<br />
Herunterladen und Entpacken der Softwarequellen:<br />
<code><br />
cd ~<br />
<br />
wget http://downloads.open-mesh.org/batman/releases/batman-adv-2013.4.0/batctl-2013.4.0.tar.gz<br />
<br />
tar xzf batctl-2013.4.0.tar.gz<br />
<br />
cd batctl-2013.4.0<br />
</code><br />
<br />
Kompilieren und Installieren:<br />
<br />
<code><br />
make<br />
<br />
make install<br />
</code><br />
<br />
Hinweis: Auch hier müssen ggf. fehlende Quellen händisch nachinstalliert und das Kompilieren und Installieren bis zum Erfolg wiederholt werden.<br />
<br><br />
== FastD ==<br />
Die Verbindung zwischen Gateway und Router wird über einen fastd-Tunnel realisiert.<br />
<br />
Hierfür müssen wir ein neues Repository in der Datei /etc/apt/sources.list deklarieren:<br />
<br />
<code><br />
vi /etc/apt/sources.list.d/universe-factory.list<br />
</code><br />
<br />
Dort fügen wir folgendes Repository an:<br />
<br />
<pre><br />
deb http://repo.universe-factory.net/debian/ sid main<br />
deb-src http://repo.universe-factory.net/debian/ sid main<br />
</pre><br />
<br />
Danach die PGP Schlüssel holen:<br />
<code><br />
gpg --keyserver hkps://hkps.pool.sks-keyservers.net --recv-key 16EF3F64CB201D9C<br />
<br />
gpg -a --export 16EF3F64CB201D9C | apt-key add -<br />
</code><br />
<br />
Datenbankupdate der Paketverwaltung:<br />
<code><br />
apt-get update<br />
</code><br />
<br />
Installation von fastd: <br />
<code><br />
apt-get install fastd <br />
</code><br />
<br><br />
<br />
== OpenVPN ==<br />
OpenVPN (falls benötigt) installieren wir mit:<br />
<code><br />
apt-get install openvpn<br />
</code><br />
<br><br />
== DHCP ==<br />
Den DHCP Server installieren wir mit:<br />
<code><br />
apt-get install isc-dhcp-server <br />
</code><br />
<br><br />
== Bind9 ==<br />
Als DNS Server nehmen wir hier den de-facto-Standard bind:<br />
<code><br />
apt-get install bind9 <br />
</code><br />
<br><br />
== OLSR ==<br />
Als Routing-Protokoll, um die einzelnen Hoods später zu einem Freifunk-Franken weit kommunizierenden Netz zu verbinden, wird OLSR installiert:<br />
<br />
<code><br />
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd_0.6.8.1-1_amd64.deb<br />
<br />
dpkg -i olsrd_0.6.8.1-1_amd64.deb<br />
<br />
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd-plugins_0.6.8.1-1_amd64.deb<br />
<br />
dpkg -i olsrd-plugins_0.6.8.1-1_amd64.deb<br />
<br />
</code><br />
<br><br />
= Konfigurieren des Freifunk-Gateways =<br />
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 />
<br><br />
== IPv4 des Gateways, IP-Bereich der Hood und DHCP Range des Gateway==<br />
Für das Gateway suchen wir uns unter [[Portal:Netz]] eine IPv4 Adresse aus dem statischen Range der Hood aus. Für Fürth läuft der Bereich für die statischen Adressen z.B. von 10.50.32.1 - 10.50.32.255. Hiervon suchen wir uns eine '''freie''' Adresse aus, und reservieren diese, indem wir sie weiter unten in die Tabelle der statischen IPs eintragen.<br />
<br />
Die Fürther Hood hat den IP-Bereich 10.50.32.0-10.50.32.255. Als Netzwerk wird dieser Bereich mit 10.50.32.0/21 deklariert, d.h. die ersten 21 Bit der IP identifizieren das Netzwerk "Fürther Hood" und die restlichen 11 Bit stehen zur IP Vergabe zur Verfügung, wobei Anfang (10.50.32.0) und Ende des Bereiches (10.50.39.255) reserviert sind und nicht, weder statisch noch dynamisch durch DHCP, belegt werden dürfen. Eine alternative Schreibweise zu 10.50.32.0/21 ist das Double "Network 10.50.32.0" und "Netmask 255.255.248.0". Ein entsprechender IP-Rechner zur analogen Anwendung in anderen Hoods findet sich z.B. [http://www.heise.de/netze/tools/netzwerkrechner/ hier].<br />
<br />
Ebenso sollte man einen DHCP-Bereich innerhalb des IP-Bereichs der jeweiligen Hood, die der GW bedienen soll, reservieren (d.h. in die oberer Tabelle unter [[Portal:Netz]] eintragen). Jeder DHCP-Server vergibt dynamisch IPv4 Adressen an Clients aus einem vorher definierten Adressbereich. Dieser Adressbereich sollte sich:<br />
* innerhalb des IP-Range der Hood bewegen<br />
* sich nicht mit dem Adressbereich überschneiden, den andere DHCP Server in der Hood verwalten<br />
* sich nicht mit dem Bereich der statischen Adressen der Hood überschneiden<br />
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. Vom gesamten IP-Bereich der Fürther Hood vergibt z.B. das Gateway fff-nue1 die Teilmenge 10.50.35.0 - 10.50.36.255 an Clients und teilt ihnen auf dem Weg auch gleich mit, wie sie Domain-Namen in IPs auflösen und auf welchem Weg sie ins Internet oder in andere Hoods kommen.<br />
<br><br />
== Routing Tabelle für Freifunk ==<br />
Fürs Routing im Freifunk Franken Netz wird eine eigene Routing Tabelle namens "fff" deklariert.<br />
<br />
Dies geschieht indem man in der Datei /etc/iproute2/rt_tables ...<br />
<code><br />
vi /etc/iproute2/rt_tables<br />
</code><br />
<br />
... folgendes am Ende einfügt:<br />
<br />
<pre><br />
10 fff<br />
</pre><br />
<br />
Unsere Freifunk Routing Tabelle lässt sich später durch<br />
<code><br />
ip route show table fff<br />
</code><br />
anzeigen, sobald wir die Tabelle mit Einträgen füllen.<br />
<br><br />
== B.A.T.M.A.N Netzwerk-Interface, fff Routingregeln und -tabelle ==<br />
'''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.<br />
<br />
In der Datei /etc/network/interfaces ...<br />
<br />
<code><br />
vi /etc/network/interfaces<br />
</code><br />
<br />
fügen wir zunächst folgenden Textblock des Gateways "klee" aus der Fürther Hood an:<br />
<br />
<pre><br />
.<br />
.<br />
.<br />
# device: bat0<br />
iface bat0 inet manual<br />
post-up ifconfig $IFACE up<br />
##Einschalten post-up:<br />
# IP des Gateways am B.A.T.M.A.N interface:<br />
post-up ip addr add 10.50.32.5/21 dev $IFACE<br />
# Regeln, wann die fff Routing-Tabelle benutzt werden soll: <br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.0.0.0/8 table fff <br />
post-up ip rule add to 10.0.0.0/8 table fff<br />
# Route in die Fuerther Hood: <br />
post-up ip route add 10.50.32.0/21 dev $IFACE table fff<br />
# Start des DHCP Servers:<br />
post-up invoke-rc.d isc-dhcp-server restart<br />
<br />
##Ausschalten post-down:<br />
# Loeschen von oben definieren Routen, Regeln und Interface: <br />
post-down ip route del 10.50.32.0/21 dev $IFACE table fff<br />
post-down ip rule del from 10.0.0.0/8 table fff<br />
post-down ip rule del to 10.0.0.0/8 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ifconfig $IFACE down<br />
<br />
# VPN Verbindung in die Fuerther Hood<br />
iface ffffuerthVPN inet manual<br />
post-up batctl -m bat0 if add $IFACE<br />
post-up ifconfig $IFACE up<br />
post-up ifup bat0<br />
post-down ifdown bat0<br />
post-down ifconfig $IFACE down<br />
</pre><br />
<br />
In diesem Beispiel sind:<br />
* IP des Gateway/Netzmaske der Fürther Hood: 10.50.32.5/21<br />
* IP des Netzwerks Fürther Hood / Netzmaske der Fürther Hood: 10.50.32.0/21.<br />
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.<br />
<br />
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.).<br />
<br />
Die Regeln definieren, das Traffic der<br />
* aus dem Netzwerk 10.0.0.0/8 kommt<br />
* das Netzwerk 10.0.0.0/8 zum Ziel hat<br />
* oder über die B.A.T.M.A.N Schnittstelle übermittelt wird<br />
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.<br />
<br />
Im post-down Abschnitt werden die vorher definierten Regeln, Interfaces und Routen wieder gelöscht.<br />
<br />
Der untere Abschnitt definiert einen VPN Tunnel in die Fürther Hood. Der Name des Interfaces im Beispiel (ffffuerthVPN) kann individuell neu vergeben werden.<br />
<br><br />
== FastD Start- und Verwaltungsscript ==<br />
Für die Konfiguration von fastd importieren wir eine Datei in ''/etc/fastd'' mit dem Befehl:<br />
<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/fff_beispiel_fastd.sh -P /etc/fastd/<br />
</code><br />
<br />
Alternativ kann das Skript aus einer leeren Datei erstellt werden:<br />
<code><br />
touch /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
danach öffnen wir diese:<br />
<br />
<code><br />
vi /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
und editieren das Skript oder fügen ein Neues ein:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
SERVERNAME="beispiel"<br />
<br />
hood="hoodeintragen"<br />
project="fff"<br />
port=10004<br />
<br />
SERVERNAME="$SERVERNAME.$hood"<br />
<br />
hostname=$SERVERNAME<br />
<br />
if [ ! -d /etc/fastd ]<br />
then<br />
mkdir /etc/fastd<br />
fi<br />
<br />
if [ ! -d /etc/fastd/$project.$hood ]<br />
then<br />
mkdir /etc/fastd/$project.$hood<br />
mkdir /etc/fastd/$project.$hood/peers<br />
<br />
#fastd config<br />
(<br />
echo "# Log warnings and errors to stderr"<br />
echo "log level error;"<br />
echo "# Log everything to a log file"<br />
echo "log to syslog as \"${project}${hood}\" level info;"<br />
echo "# Set the interface name"<br />
echo "interface \"${project}${hood}VPN\";"<br />
echo "# Support xsalsa20 and aes128 encryption methods, prefer xsalsa20"<br />
echo "#method \"xsalsa20-poly1305\";"<br />
echo "#method \"aes128-gcm\";"<br />
echo "method \"null\";"<br />
echo "# Bind to a fixed port, IPv4 only"<br />
echo "bind any:${port};"<br />
echo "# Secret key generated by \"fastd --generate-key\""<br />
echo "secret \"$(fastd --generate-key | grep -i Secret | awk '{print $2}')\";" <br />
echo "# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)" <br />
echo "# (see MTU selection documentation)" <br />
echo "mtu 1426;" <br />
echo "on up \"/etc/fastd/${project}.${hood}/up.sh\";" <br />
echo "on post-down \"/etc/fastd/${project}.${hood}/down.sh\";" <br />
echo "# Include peers from the directory 'peers'" <br />
echo "include peers from \"/etc/fastd/${project}.${hood}/peers\";" <br />
echo "secure handshakes no;"<br />
) >> "/etc/fastd/$project.$hood/$project.$hood.conf"<br />
<br />
#fastd-up<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifdown \$INTERFACE"<br />
) >> /etc/fastd/$project.$hood/down.sh<br />
<br />
chmod +x /etc/fastd/$project.$hood/down.sh<br />
<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifup \$INTERFACE" >> /etc/fastd/$project.$hood/up.sh<br />
) >> /etc/fastd/$project.$hood/up.sh<br />
chmod +x /etc/fastd/$project.$hood/up.sh<br />
fi<br />
<br />
pubkey=$(fastd -c /etc/fastd/$project.$hood/$project.$hood.conf --show-key --machine-readable)<br />
port=$(grep ^bind /etc/fastd/$project.$hood/$project.$hood.conf | cut -d: -f2 | cut -d\; -f1)<br />
<br />
# fire up<br />
if [ "$(/sbin/ifconfig -a | grep -i ethernet | grep ${project}${hood}VPN)" = "" ]<br />
then<br />
/bin/rm /var/run/fastd.$project.$hood.pid<br />
fastd -c /etc/fastd/$project.$hood/$project.$hood.conf -d --pid-file /var/run/fastd.$project.$hood.pid<br />
fi<br />
<br />
# register<br />
wget -T15 -q "http://keyserver.freifunk-franken.de/${project}/?name=$hostname&port=$port&key=$pubkey" -O /tmp/fastd_${project}.${hood}_output <br />
if [ "$?" != "0" ]<br />
then<br />
echo "Update failed"<br />
echo "Exiting, no clean up, no refresh"<br />
exit<br />
fi<br />
<br />
touch /tmp/fastd_${project}.${hood}_starting<br />
<br />
filenames=$(cat /tmp/fastd_${project}.${hood}_output| grep ^#### | sed -e 's/^####//' | sed -e 's/.conf//g')<br />
for file in $filenames<br />
do<br />
grep -A100 ^####$file.conf$ /tmp/fastd_${project}.${hood}_output | grep -v ^####$file.conf$ | grep -m1 ^### -B100 | grep -v ^### | sed 's/ float;/;/g' > "/etc/fastd/$project.$hood/peers/$file"<br />
echo 'float yes;' >> "/etc/fastd/$project.$hood/peers/$file"<br />
done<br />
<br />
#find old peers<br />
OLD=$(find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print)<br />
<br />
if [ -n "${OLD}" ] ; then<br />
echo "Lösche alte:"<br />
echo $OLD<br />
<br />
find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print | xargs /bin/rm /tmp/fastd_${project}.${hood}_starting<br />
fi<br />
<br />
#reload<br />
kill -HUP "$(cat /var/run/fastd.$project.$hood.pid)"<br />
<br />
exit 0<br />
</pre><br />
<br />
Zum Schluss geben wir noch ein<br />
<br />
<code><br />
chmod +x /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
ein, um das Skript ausführbar zu machen.<br />
<br />
Das Skript konfiguriert fastd, indem es<br />
* einen Schlüssel generiert, sollte keiner existieren<br />
* diesen Schlüssel mit dem Keyserver austauscht<br />
* die fastd Konfigurationsdatei anlegt<br />
* den fastd Dämonen startet<br />
<br />
Lediglich der Servername und die Hood müssen oben im Skript händisch angepasst werden. Der Dateiname des Skripts kann individuell angepasst werden.<br />
<br />
Nachdem das Script ausgeführt wurde, sollte man überprüfen ob das Interface in der Konfigurationsdatei unter /etc/fastd/fff.<Hoodname>/fff.<Hoodname>.conf das gleiche ist wie vorher in /etc/network/interfaces festgelegt. Wenn der Name nicht identisch ist (Groß-/Kleinschreibung), werden die Interfaces nicht starten.<br />
<br />
Hinweis: Das Gateway wird standardmässig in die Default-Hood eingebunden. Es wird hier lediglich ein Name für die Konfigurationsdatei und der Gateway Name definiert. Die Zuordnung des Gateways zu der Hood erfolgt später über den KeyXchange (siehe unten).<br />
<br><br />
== IP-Forwarding ==<br />
Um Anfragen, die das Gateway erreichen, weiterzuleiten, muss IP-Forwarding aktiviert werden. <br />
<br />
Manuell geht dies über:<br />
<code><br />
echo "1" > /proc/sys/net/ipv4/ip_forward<br />
<br />
echo "1" > /proc/sys/net/ipv6/conf/default/forwarding<br />
<br />
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding<br />
</code><br />
<br />
Dauerhaft lässt sich IP-Forwarding in /etc/sysctl.conf aktivieren:<br />
<code><br />
vi /etc/sysctl.conf<br />
</code><br />
<br />
.. um dort die Abschnitte einzukommentieren, die das Forwarding steuern:<br />
<pre><br />
.<br />
.<br />
.<br />
# Uncomment the next line to enable packet forwarding for IPv4<br />
net.ipv4.ip_forward=1<br />
<br />
# Uncomment the next line to enable packet forwarding for IPv6<br />
# Enabling this option disables Stateless Address Autoconfiguration<br />
# based on Router Advertisements for this host<br />
net.ipv6.conf.all.forwarding=1<br />
.<br />
.<br />
.<br />
</pre><br />
<br><br />
== Testen von B.A.T.M.A.N, fastd und Autostart ==<br />
Hierfür booten wir das Gateway am besten erst mal neu:<br />
<code><br />
reboot & exit<br />
</code><br />
<br />
und starten das fast.d Startskript manuell: <br />
<code><br />
/etc/fastd/fff_beispiel_fastd.sh &<br />
</code><br />
<br />
Beim Erststart werden Schlüsselpaare generiert und ausgetauscht, es kann also etwas dauern.<br />
<br />
Danach sollte der Aufruf von...<br />
<code><br />
pgrep fastd<br />
</code><br />
... mit der Prozess-ID beantwortet werden: Fastd läuft in dem Fall.<br />
<br />
<br />
Ein Aufruf von ifconfig:<br />
<code><br />
ifconfig<br />
</code><br />
<br />
sollte die neu erstellten Interfaces bat0 und ffffuerthVPN zurückliefern.<br />
Exemplarisch und als Auszug:<br />
<pre><br />
bat0 Link encap:Ethernet HWaddr ea:95:50:07:f7:27 <br />
inet addr:10.50.32.5 Bcast:0.0.0.0 Mask:255.255.248.0<br />
inet6 addr: fe80::e895:50ff:fe07:f727/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:1089992 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:849698 errors:0 dropped:1728 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0 <br />
RX bytes:141311612 (134.7 MiB) TX bytes:1052934594 (1004.1 MiB)<br />
<br />
.<br />
.<br />
.<br />
ffffuerthVPN Link encap:Ethernet HWaddr e6:3b:f3:b7:fc:db <br />
inet6 addr: fe80::e43b:f3ff:feb7:fcdb/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1426 Metric:1<br />
RX packets:32389694 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:2699525 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:500 <br />
RX bytes:4193328694 (3.9 GiB) TX bytes:1384843740 (1.2 GiB)<br />
.<br />
.<br />
.<br />
</pre><br />
Aus dem ifconfig Auszug für bat0 sollte die eingerichtete IP des Gateways und die Netzmaske hervorgehen.<br />
<br />
<br />
Die Abfrage der IP-Regeln:<br />
<code><br />
ip rule<br />
</code><br />
<br />
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):<br />
<pre><br />
32757: from all to 10.0.0.0/8 lookup fff <br />
32758: from 10.0.0.0/8 lookup fff <br />
32759: from all iif bat0 lookup fff <br />
</pre><br />
<br />
Eine Abfrage der fff-Routing Tabelle<br />
<code><br />
ip route show table fff <br />
</code><br />
<br />
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:<br />
<pre><br />
10.50.32.0/21 dev bat0 scope link<br />
</pre><br />
<br />
Ein Aufruf von "batctl o"<br />
<code><br />
batctl o <br />
</code><br />
<br />
ergibt eine Liste der MAC-Adressen von unseren nächsten Nachbarn. Exemplarisch und als Auszug:<br />
<pre><br />
[B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: ffffuerthVPN/e6:3b:f3:b7:fc:db (bat0)]<br />
Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ...<br />
96:43:c4:2e:73:68 0.004s (255) 96:43:c4:2e:73:68 [ffffuerthVPN]: 96:43:c4:2e:73:68 (255)<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
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:<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
Hier spendieren wir einen Eintrag, der fastd mit 10 Sekunden Verzögerung bei jedem Systemstart mitstartet:<br />
<pre><br />
# launch fastd with 10 seconds delay<br />
(sleep 10; sh /etc/fastd/fff_beispiel_fastd.sh) &<br />
</pre><br />
<br />
'''Zusätzlich''' muss ein Cronjob angelegt werden, der das Skript z.B. alle 10 Minuten ausführt:<br />
<code><br />
crontab -e<br />
</code><br />
<br />
Nun folgendes eingeben:<br />
<pre><br />
*/10 * * * * sh /etc/fastd/fff_beispiel_fastd.sh<br />
</pre><br />
<br />
und<br />
<br />
<code><br />
/etc/init.d/cron restart<br />
</code><br />
<br><br />
== OpenVPN-Tunnel einrichten ==<br />
Die Einrichtung eines OpenVPN Tunnels kann von Anbieter zu Anbieter variieren. <br />
Im Laufe der Zeit sollte die Dokumentation so um funktionierende Konfigurationen verschiedener Anbieter erweitert werden.<br />
<br><br />
=== Mullvad ===<br />
Mullvad liefert in der Datei mullvadconfig.zip, die notwendigen Schlüssel (ca.crt, mullvad.crt, mullvad.key) als auch eine Konfigurationsdatei (mullvad_linux.conf) mit, die später angepasst werden muss.<br />
<br />
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:<br />
<br />
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.<br />
<br />
Als unverbindliche Richtschnur für Linux:<br />
<code><br />
scp mullvadconfig.zip root@<ipv4 des Gateways>:/root<br />
</code><br />
<br />
Danach loggen wir uns auf dem Gateway ein und entpacken die Datei (nicht vergessen unzip zu installieren):<br />
<code><br />
ssh root@<ipv4 des Gateways><br />
<br />
unzip mullvadconfig.zip<br />
<br />
cd <Kundennummernverzeichnis><br />
<br />
cp * /etc/openvpn<br />
</code><br />
<br />
''/etc/openvpn/'' sollte mit dem Inhalt des entpackten mullvadconfig.zip Archivs dann so aussehen:<br />
<pre><br />
ca.crt crl.pem mullvad.crt mullvad.key mullvad_linux.conf mullvad-up mullvad_windows.conf.ovpn <br />
</pre><br />
<br />
'''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.<br />
<br />
Wir legen ein benutzerspezifisches start-up Script namens mullvad-up an:<br />
<code><br />
vi /etc/openvpn/mullvad-up<br />
</code><br />
<br />
und füllen sie mit folgendem Inhalt:<br />
<pre><br />
#!/bin/bash<br />
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE<br />
</pre><br />
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.<br />
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.<br />
<br />
Das Skript mullvad-up muss ferner ausführbar sein:<br />
<code><br />
chmod +x /etc/openvpn/mullvad-up<br />
</code><br />
<br />
Dieses spezifische Routing muss zwingend in mullvad_linux.conf eingepflegt werden:<br />
<code><br />
vi /etc/openvpn/mullvad_linux.conf<br />
</code><br />
<br />
und hier die Konfiguration entsprechend geändert werden:<br />
<pre><br />
.<br />
.<br />
.<br />
# Allow calling of built-in executables and user-defined scripts.<br />
script-security 2<br />
<br />
# Parses DHCP options from openvpn to update resolv.conf<br />
#up /etc/openvpn/update-resolv-conf<br />
#down /etc/openvpn/update-resolv-conf<br />
<br />
# Enable Freifunk specific Routing<br />
route-noexec<br />
route-delay 3<br />
route-up /etc/openvpn/mullvad-up<br />
.<br />
.<br />
.<br />
</pre><br />
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.<br />
<br />
Wer möchte, kann in mullvad_linux.conf auch Länder definieren, über die der VPN Traffic laufen soll (Ein- /Auskommentieren).<br />
<br />
Der openvpn Tunnel kann nun testweise gestartet werden:<br />
<code><br />
cd /etc/openvpn<br />
<br />
/usr/sbin/openvpn mullvad_linux.conf &<br />
</code><br />
<br />
und sollte exemplarisch und im Auszug folgendes zurück liefern:<br />
<pre><br />
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<br />
Sun Sep 6 12:45:20 2015 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08<br />
Sun Sep 6 12:45:20 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts<br />
.<br />
.<br />
.<br />
Sun Sep 6 12:45:23 2015 /sbin/ip link set dev tun0 up mtu 1500<br />
Sun Sep 6 12:45:23 2015 /sbin/ip addr add dev tun0 10.114.0.45/16 broadcast 10.114.255.255<br />
Sun Sep 6 12:45:23 2015 /sbin/ip -6 addr add fdef:e287:a479:72::102b/112 dev tun0<br />
Sun Sep 6 12:45:23 2015 /etc/openvpn/mullvad-up tun0 1500 1558 10.114.0.45 255.255.0.0 init<br />
Sun Sep 6 12:45:23 2015 Initialization Sequence Completed<br />
</pre><br />
Wichtig ist hierbei, dass in der vorletztes Zeile unser Freifunk-spezifisches Routing durchgeführt wird.<br />
<br />
Das VPN-Gateway sollte nun als Default Route in der fff-Routingtabelle auftauchen:<br />
<code><br />
ip route show table fff | grep default<br />
</code><br />
<br />
Exemplarisch wäre eine Ausgabe für das Tunnel-Device tun0 und dem VPN-Gateway 10.114.0.1:<br />
<pre><br />
default via 10.114.0.1 dev tun0<br />
</pre><br />
<br />
Auch ein ifconfig Eintrag für das Tunnel Device...<br />
<code><br />
ifconfig<br />
</code><br />
<br />
...sollte jetzt existieren (Exemplarisch und im Auszug):<br />
<pre><br />
.<br />
.<br />
.<br />
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 <br />
inet addr:10.114.0.76 P-t-P:10.114.0.76 Mask:255.255.0.0<br />
inet6 addr: fdad:bdef:735d:72::104a/112 Scope:Global<br />
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1<br />
RX packets:1012476 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:640206 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:100 <br />
RX bytes:1250196616 (1.1 GiB) TX bytes:84979294 (81.0 MiB)<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
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:<br />
<code><br />
vi /etc/rc.local <br />
</code><br />
<br />
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:<br />
<pre><br />
# launch vpn with 5 seconds delay<br />
(sleep 5; /usr/sbin/openvpn /etc/openvpn/mullvad_linux.conf >> /var/log/mullvad_vpn.log &) &<br />
</pre><br />
<br><br />
<br />
=== NordVPN ===<br />
NordVPN liefert die Datei config.zip mit, die für jeden verwendbaren VPN-Server eine seperate Konfigurationsdatei enthält.<br />
<br />
'''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.<br />
<br />
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.<br />
<br />
Als unverbindliche Richtschnur für Linux:<br />
<code><br />
scp config.zip root@<ipv4 des Gateways>:/root<br />
</code><br />
<br />
Und entpacken diese auf dem Gateway:<br />
<code><br />
cd ~<br />
<br />
mkdir nordvpn-configs<br />
<br />
mv config.zip nordvpn-configs<br />
<br />
cd nordvpn-configs<br />
<br />
unzip config.zip<br />
</code><br />
<br />
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.<br />
<br />
Im Beispiel nehmen wir se1.nordvpn.com.udp1194.ovpn und passen Sie zunächst Freifunk-spezifisch an (siehe Aussperr-Hinweis oben):<br />
<br />
<code><br />
vi se1.nordvpn.com.udp1194.ovpn<br />
</code><br />
<br />
Ä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:<br />
<pre><br />
.<br />
.<br />
.<br />
# Provide Username and Password<br />
auth-user-pass /etc/openvpn/nordvpn-pw<br />
.<br />
.<br />
.<br />
# Allow calling of built-in executables and user-defined scripts.<br />
script-security 2<br />
<br />
# Enable Freifunk specific Routing<br />
route-noexec<br />
route-delay 3<br />
route-up /etc/openvpn/nordvpn-up<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
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:<br />
<code><br />
cp se1.nordvpn.com.udp1194.ovpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf<br />
</code><br />
<br />
Hier legen wir noch unser Freifunk Startskript und unsere Password Datei an und machen das Skript ausführbar:<br />
<code><br />
touch /etc/openvpn/nordvpn-up<br />
<br />
touch /etc/openvpn/nordvpn-pw<br />
<br />
chmod +x /etc/openvpn/nordvpn-up<br />
</code><br />
<br />
Man öffnet nordvpn-up...<br />
<code><br />
vi /etc/openvpn/nordvpn-up<br />
</code><br />
<br />
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):<br />
<pre><br />
#!/bin/bash<br />
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE<br />
</pre><br />
<br />
Nun öffnet man nordvpn-pw:<br />
<code><br />
vi /etc/openvpn/nordvpn-pw<br />
</code><br />
<br />
Und legt in der ersten Zeile der Datei seinen NordVPN Usernamen und in der zweiten Zeile sein NordVPN Passwort ab:<br />
<pre><br />
(Username bei NordVPN)<br />
(Password bei NordVPN)<br />
</pre><br />
<br />
Der Tunnel kann nun testweise gestartet werden (hier im Beispiel mit der Konfigurationsdatei se1.nordvpn.com.udp1194.ovpn)<br />
<code><br />
openvpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf &<br />
</code><br />
<br />
Und sollte aufgebaut werden:<br />
<pre><br />
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<br />
.<br />
.<br />
.<br />
Sun Sep 27 09:07:15 2015 /sbin/ip link set dev tun0 up mtu 1500<br />
Sun Sep 27 09:07:15 2015 /sbin/ip addr add dev tun0 local 10.8.8.226 peer 10.8.8.225<br />
Sun Sep 27 09:07:18 2015 Initialization Sequence Completed<br />
</pre><br />
<br />
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:<br />
<code><br />
vi /etc/rc.local <br />
</code><br />
<br />
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:<br />
<pre><br />
# launch vpn with 5 seconds delay<br />
(sleep 5; cd /etc/openvpn ; /usr/sbin/openvpn se1.nordvpn.com.udp1194.ovpn.conf >> /var/log/nordvpn.log &) &<br />
</pre><br />
Die Beispiel-Konfigurationsdatei (se1.nordvpn.com.udp1194.ovpn.conf) muss entsprechend angepasst werden.<br />
<br><br />
== DNS Server ==<br />
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.<br />
<br />
----<br />
<br />
'''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.'''<br />
<br />
----<br />
<br />
Hierfür editieren wir die Datei named.conf.options...<br />
<code><br />
vi /etc/bind/named.conf.options<br />
</code><br />
<br />
...und tragen die DNS Server, die wir anfragen wollen, wenn wir die Information nicht selber haben, als forwarders ein:<br />
<pre><br />
.<br />
.<br />
.<br />
forwarders {<br />
10.50.32.1;<br />
10.50.32.2;<br />
8.8.8.8;<br />
};<br />
allow-query { <br />
127.0.0.1/8; <br />
10.0.0.0/8; <br />
};<br />
.<br />
.<br />
. <br />
</pre><br />
In diesem Fall werden die Freifunk Gateways ro1 (10.50.32.1) und fff-nue1 (10.50.32.2) der Fürther Hood als auch Google DNS (8.8.8.8) als Forwarders definiert. Für andere Hoods muss die lokale Adresse der Freifunk DNS Server unter [[Portal:Netz]] ermittelt werden (z.B. 10.50.48.1 für ro1 in der Ansbacher Hood).<br />
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".<br />
<br />
Neustart des DNS-Servers mit der neuen Konfiguration:<br />
<code><br />
/etc/init.d/bind9 restart<br />
</code><br />
<br />
Testen können wir, indem wir vom DNS Server des Gateways (localhost/127.0.0.1) eine DNS-Auflösung abfragen. <br />
<br />
Ein DNS Resolve für freifunk-franken.de ...<br />
<code><br />
dig @127.0.0.1 freifunk-franken.de<br />
</code><br />
<br />
...sollte von uns selber (Server localhost; 127.0.0.1) beantwortet werden:<br />
<pre><br />
;; global options: +cmd<br />
<br />
;; Got answer:<br />
<br />
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5819<br />
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1 <br />
;; OPT PSEUDOSECTION:<br />
; EDNS: version: 0, flags:; udp: 4096<br />
<br />
;; QUESTION SECTION:<br />
;freifunk-franken.de. IN A<br />
;; ANSWER SECTION:<br />
freifunk-franken.de. 3599 IN A 31.172.113.113 <br />
.<br />
. <br />
.<br />
;; Query time: 117 msec<br />
;; SERVER: 127.0.0.1#53(127.0.0.1)<br />
;; WHEN: Tue Sep 08 14:16:32 EEST 2015<br />
;; MSG SIZE rcvd: 275<br />
</pre><br />
<br><br />
<br />
== B.A.T.M.A.N Gateway Selection ==<br />
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.<br />
<br />
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:<br />
* Bandbreite der Netzanbindung (z.B. 100 Mbit/sec, gesplittet in 50 Mbit/sec up/down)<br />
* 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)<br />
* Erfahrungswerten / eigenes Ermessen<br />
* Bandbreite, bei dem der Gateway Prozessor ausgelastet ist<br />
<br />
Eventuell muss zuerst bc nachinstalliert werden, falls nicht vorhanden:<br />
<code><br />
apt-get install bc<br />
</code><br />
<br />
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.<br />
<br />
Importieren des Skripts aus einer Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/dyn_announce_gw_bw.sh -P /usr/local/bin/<br />
</code><br />
<br />
Alternativ kann das Skript auch als leere Datei erstellt werden:<br />
<code><br />
touch /usr/local/bin/dyn_announce_gw_bw.sh<br />
</code><br />
<br />
Wir machen das Skript ausführbar und öffnen die Datei:<br />
<code><br />
chmod +x /usr/local/bin/dyn_announce_gw_bw.sh<br />
<br />
vi /usr/local/bin/dyn_announce_gw_bw.sh<br />
</code><br />
<br />
Und Füllen dieses mit Inhalt oder editieren den importierten Inhalt:<br />
<pre><br />
#!/bin/bash<br />
gwsel_lockfile="/tmp/gwsel_lockfile" # lockfile to allow for low bandwidth settings <br />
<br />
if [ -z "$1" ]; then<br />
echo<br />
echo "usage: $0 <network-interface> <update_interval [sec]> <total BW up [Mbit/sec]> <total BW down [Mbit/sec]>"<br />
echo<br />
echo "e.g. $0 eth0 60 10 10"<br />
echo<br />
exit<br />
fi<br />
<br />
while true<br />
do<br />
if [ ! -e ${gwsel_lockfile} ]; then # lockfile not present<br />
# Bandwidth currently used (time averaged)<br />
R1=$(cat "/sys/class/net/$1/statistics/rx_bytes")<br />
T1=$(cat "/sys/class/net/$1/statistics/tx_bytes")<br />
sleep "$2"<br />
R2=$(cat "/sys/class/net/$1/statistics/rx_bytes")<br />
T2=$(cat "/sys/class/net/$1/statistics/tx_bytes")<br />
TkbitPS=$(echo "scale=0; ($T2 - $T1) / 1024 * 8 / $2" | bc -l)<br />
RkbitPS=$(echo "scale=0; ($R2 - $R1) / 1024 * 8 / $2" | bc -l)<br />
# echo "BW used -- up $1: $TkbitPS kBit/s; down $1: $RkbitPS kBit/s"<br />
<br />
# Remaining bandwidth available; cut-off negative values<br />
Tavail_kbitPS=$(echo "scale=0; if (($3 * 1024 - $TkbitPS) >0) ($3 * 1024 - $TkbitPS) else 0" | bc -l)<br />
Ravail_kbitPS=$(echo "scale=0; if (($4 * 1024 - $RkbitPS) >0) ($4 * 1024 - $RkbitPS) else 0" | bc -l)<br />
# echo "BW available -- up $1: $Tavail_kbitPS kBit/s; down $1: $Ravail_kbitPS kBit/s"<br />
else # lockfile present<br />
Tavail_kbitPS=0<br />
Ravail_kbitPS=0<br />
sleep "$2"<br />
fi<br />
<br />
for bat in /sys/class/net/bat*; do<br />
iface=${bat##*/}<br />
batctl -m $iface gw_mode server "${Ravail_kbitPS}kbit/${Tavail_kbitPS}kbit" <br />
done<br />
done<br />
</pre><br />
<br />
Das Skript übernimmt als Parameter:<br />
* Netzwerkinterface, das es zu überwachen gilt (i.d.R. eth0)<br />
* 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)<br />
* Upload Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)<br />
* Download Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)<br />
<br />
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 olsr Defaultroute mit geringer Bandbreite verfügbar ist.<br />
<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.:<br />
<code><br />
/usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10<br />
</code><br />
<br />
Um die Gateway Selection beim Systemsstart zu aktivieren, können wir das Skript z.B. in rc.local aufrufen:<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
um dort, leicht zeitverzögert, o.a. Befehl einzupflegen, wobei die Parametrisierung noch Gateway-spezifisch angepasst werden muss:<br />
<pre><br />
.<br />
.<br />
.<br />
#enable batman GW selection with 15 seconds delay<br />
(sleep 15; /usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10) &<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
ACHTUNG! Bei mehreren bat Interfaces (weil man in mehreren Hoods Gateway ist) muss diese Einstellung für jedes Gateway gesetzt werden, hier muss das Script unbedingt überarbeitet werden!<br />
<br />
<pre><br />
batctl -m $batX gw_mode xxmbit/xxmbit<br />
</pre><br />
<br />
und dies für jedes batX Interface. Das Script muss daraufhin noch angepasst werden.<br />
<br />
<br />
auf den Routern kann der vorselektierte Gateway mit <br />
<br />
<code><br />
batctl gwl<br />
</code><br />
<br />
angeguckt werden. Ich vermute das der Gateway mit den Pfeil vorne der vorselektierte Gateway ist, allerdings machen erste beobachtete Daten bisher in meinen Augen noch keinen wirklichen Sinn.<br />
<br><br />
<br />
== DHCP Server ==<br />
Die DHCP Konfiguration kann schon mal vorbereitet werden, sollte aber erst mit als letzter Schritt scharf geschaltet werden. Ein DHCP-Server, der Clients nicht funktionierende DNS-Server oder ein nicht funktionierendes Gateway mitteilt, sperrt diese aus dem Freifunk Netz aus.<br />
<br />
In isc-dhcp-server definieren wir ...<br />
<code><br />
vi /etc/default/isc-dhcp-server<br />
</code><br />
<br />
... das der DHCP Server für das B.A.T.M.A.N Device Anfragen beantworten soll:<br />
<pre><br />
.<br />
.<br />
<br />
INTERFACES="bat0"<br />
.<br />
.<br />
</pre><br />
<br />
Nachfolge Konfiguration wird in auskommentierter Form vorbereitet und sollte erst im letzten Schritt durch Einkommentieren und durch einen Neustart des DHCP Servers...<br />
<code><br />
/etc/init.d/isc-dhcp-server restart<br />
</code><br />
...aktiviert werden.<br />
<br />
Die Konfiguration wird in dhcpd.conf vorgenommen:<br />
<code><br />
vi /etc/dhcp/dhcpd.conf<br />
</code><br />
<br />
und folgender Konfigurationsblock zunächst auskommentiert eingefügt, wobei Gateway und Hood spezifische Änderungen noch eingepflegt werden müssen:<br />
<pre><br />
.<br />
.<br />
.<br />
### Freifunk Franken<br />
#option domain-name "fff.community";<br />
#option domain-name-servers 10.50.16.1;<br />
#authoritative;<br />
### Fuerth<br />
#subnet 10.50.32.0 netmask 255.255.248.0 { # Netzwerk und Netzmaske der Fuerther Hood<br />
# range 10.50.38.0 10.50.39.254; # IP-Range die der DHCP-Server innerhalb der Fuerther Hood verwaltet <br />
# option routers 10.50.32.5; # Default-Gateway, dass Clients mitgeteilt wird <br />
# option domain-name-servers 10.50.32.5, 10.50.32.1; # Name-Server, die Clients mitgeteilt werden<br />
#}<br />
</pre><br />
<br />
Netzwerk und Netzmaske müssen derjenigen der Hood des Gateways entsprechen. Im Beispiel ist dies Fürth, für z.B. Hassberge hieße der Eintrag "subnet 10.50.56.0 netmask 255.255.252.0".<br />
<br />
Der IP-Bereich (Range), die der DHCP-Server in der Hood verwaltet, wurde zuvor unter [[Portal:Netz]] reserviert.<br />
<br />
Unter Routers wird den Clients das Default-Gateway mitgeteilt: Das Gateway, über das Clients das Internet oder eine andere Hood erreichen. In unserem Beispiel routet das aufgesetzte Gateway selber via VPN ins Internet oder via olsr (später) in andere Hoods. Als Default-Gateway wird also die eigene statische IP des Gateways, aus der eigenen Hood, die in [[Portal:Netz]] reserviert wurde, verwendet.<br />
<br />
Ähnlich verhält es sich mit den Nameservern: Auf unserem Gateway wurde ein DNS Server eingerichtet, also kann der domain-name-server unser eigenes Gateway, mit der reservierten statische IP aus der Hood, wie in [[Portal:Netz]], sein. Als Backup empfiehlt sich ein weiterer DNS-Server aus der Hood, in unserem Beispiel ro1 in der Fürther.<br />
<br><br />
<br />
== GRE-Tunnel zu anderen Gateways ==<br />
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]].<br />
<br />
Der GRE-Tunnel wird in /etc/network/interfaces...<br />
<code><br />
vi /etc/network/interfaces<br />
</code><br />
<br />
...mit folgenden noch auf das Gateway anzupassenden Einträgen deklariert:<br />
<pre><br />
auto <tunnel><br />
iface <tunnel> inet static<br />
address <Eigene IPv4 (Freifunk Netz)><br />
pre-up ip -4 tunnel add $IFACE mode gre local <Eigene IPv4 (Internet)> remote <IPv4 des Tunnelpartners (Internet)> ttl 255<br />
#pre-up ip -6 tunnel add $IFACE mode ip6gre local <Eigene IPv6 (Internet)> remote <IPv6 des Tunnelpartners (Internet)> ttl 255<br />
<br />
up ifconfig $IFACE multicast<br />
pointopoint <IPv4 des Tunnelpartners (Freifunk Netz)><br />
post-up iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu<br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.50.0.0/16 table fff<br />
post-up ip rule add to 10.50.0.0/16 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ip rule del from 10.50.0.0/16 table fff<br />
post-down ip rule del to 10.50.0.0/16 table fff<br />
post-down iptables -t mangle -D POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu<br />
post-down iptunnel del $IFACE<br />
</pre><br />
<br />
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.<br />
<br />
'''Beispiel:''' <br />
Um als fff-nue1 einen Tunnel zu ro1 aufzubauen, können die IP-Adressen wie folgt gewählt werden:<br />
<pre><br />
<tunnel> ro1<br />
<Eigene IPv4 (Freifunk Netz)> fff-nue1 10.50.252.1<br />
<IPv4 des Tunnelpartners (Freifunk Netz)> ro1 10.50.252.0<br />
<Eigene IPv4 (Internet)> fff-nue1 31.172.33.99<br />
<IPv4 des Tunnelpartners (Internet)> ro1 176.126.221.7<br />
</pre><br />
<br />
In der Partnerkonfiguration für ro1 werden die Rollen entsprechend vertauscht:<br />
<pre><br />
<tunnel> fff-nue1<br />
<Eigene IPv4 (Freifunk Netz)> ro1 10.50.252.0<br />
<IPv4 des Tunnelpartners (Freifunk Netz)> fff-nue1 10.50.252.1<br />
<Eigene IPv4 (Internet)> ro1 176.126.221.7<br />
<IPv4 des Tunnelpartners (Internet)> fff-nue1 31.172.33.99 <br />
</pre><br />
<br />
Der Tunnel kann über den Aufruf von<br />
<code><br />
ifup <tunnel><br />
</code><br />
...aufgebaut werden, wobei <tunnel> der Name des GRE-Interfaces ist (im Beispiel ro1)<br />
<br />
Nach Aufruf von ifconfig..<br />
<code><br />
ifconfig <br />
</code><br />
sollten wir einen Eintrag für den Tunnel (in diesem Beispiel ro1) vorfinden:<br />
<pre><br />
.<br />
.<br />
.<br />
ro1 Link encap:UNSPEC HWaddr B0-7B-1C-73-30-30-3A-35-00-00-00-00-00-00-00-00 <br />
inet addr:10.50.252.1 P-t-P:10.50.252.0 Mask:255.255.255.255<br />
inet6 addr: fe80::200:5efe:b07b:1c73/64 Scope:Link<br />
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1476 Metric:1<br />
RX packets:160913 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:146654 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0 <br />
RX bytes:66984353 (63.8 MiB) TX bytes:10675001 (10.1 MiB)<br />
.<br />
.<br />
.<br />
</pre><br />
<br><br />
== OLSR ==<br />
=== Basiskonfiguration ===<br />
Mittels OLSR können die Gateways selbstständig Routinginformationen austauschen. Ähnlich wie B.A.T.M.A.N einzelne Router innerhalb einer Hood vermesht (Level 2 Netz), handelt es sich bei olsr um ein mesh zwischen den Gateways (Level 3). Es ermöglicht ein Freifunk Franken internes Routing: z.B. kann eine beliebige IPv4 aus der Nürnberger Hood aus der Fürth Hood heraus erreicht werden.<br />
<br />
Vorlagen können unter Sicherung der Originaldateien wie folgt importiert werden:<br />
<code><br />
mv /etc/default/olsrd /etc/default/olsrd.orig<br />
<br />
mv /etc/olsrd/olsrd.conf /etc/olsrd/olsrd.conf.orig<br />
<br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd -P /etc/default/<br />
<br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd.conf -P /etc/olsrd/<br />
</code><br />
<br />
Zunächst zeigen wir die Interfaces an, unter dem wir olsr Routing Informationen austauschen:<br />
<code><br />
vi /etc/default/olsrd<br />
</code><br />
<br />
Im Beispiel wird über die 2 GRE-Tunnel nue1 und ro1 ausgetauscht, dies muss entsprechend der GRE-Tunnel Konfiguration angepasst werden: <br />
<pre><br />
.<br />
.<br />
#<br />
# Uncomment the next line run olsrd automatically at startup<br />
#<br />
START_OLSRD="YES"<br />
<br />
#<br />
# Uncomment the next line to force-configure the wifi interface to be setup<br />
# for ad-hoc mode using the /usr/sbin/olsrd-adhoc-setup script whenever olsrd<br />
# is started.<br />
#<br />
SETUP_ADHOC="NO"<br />
.<br />
.<br />
.<br />
#<br />
# Specify the network interfaces that olsrd will run on, this will most likely<br />
# be your wifi interface.<br />
#<br />
MESH_IF="nue1 ro1" <br />
.<br />
.<br />
</pre><br />
<br />
<br />
Weiter wird dann hier ...<br />
<code><br />
vi /etc/olsrd/olsrd.conf<br />
</code><br />
... konfiguriert. <br />
Da unser Beispiel-Gateway ins Netz der Fürther Hood eingebunden ist, teilen wir dies andern Gateways über den Eintrag 10.50.32.0/21 mit:<br />
<pre><br />
.<br />
.<br />
.<br />
# HNA IPv4 routes<br />
# syntax: netaddr netmask<br />
# Example Internet gateway:<br />
# 0.0.0.0 0.0.0.0<br />
<br />
Hna4<br />
{<br />
# Internet gateway:<br />
# 0.0.0.0 0.0.0.0<br />
# more entries can be added:<br />
# 192.168.1.0 255.255.255.0<br />
10.50.32.0/21<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Hier wird das olsr Webinterface auf port 8080 konfiguriert:<br />
<br />
<pre><br />
.<br />
.<br />
.<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
# defaults to 1978<br />
PlParam "Port" "8080"<br />
# if you dont set these, the default is to listen only on the loopback device<br />
#PlParam "Host" "80.23.53.22"<br />
#PlParam "Net" "10.0.0.0 255.0.0.0"<br />
PlParam "Net" "0.0.0.0 0.0.0.0"<br />
#PlParam "Host" "127.0.0.1"<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Ferner wird der VPN-Tunnel (hier tun0) per persönlich angepasstem ping Kommando auf sein Funktion hin überwacht. Sollte der VPN-Tunnel ausfallen, ermöglicht olsr im Zusammenspiel mit der Routing Priorisierung (s.u) und der OpenVPN Start-/Stop Automatik (s.u.) ein automatisches Re-Routing:<br />
<pre><br />
.<br />
.<br />
.<br />
LoadPlugin "olsrd_dyn_gw.so.0.5"<br />
{<br />
# Here parameters are set to be sent to the<br />
# plugin. Theese are on the form "key" "value".<br />
# Parameters ofcause, differs from plugin to plugin.<br />
# Consult the documentation of your plugin for details.<br />
<br />
# Example: dyn_gw params<br />
<br />
# how often to check for Internet connectivity<br />
# defaults to 5 secs<br />
PlParam "Interval" "5"<br />
<br />
# if one or more IPv4 addresses are given, do a ping on these in<br />
# descending order to validate that there is not only an entry in<br />
# routing table, but also a real internet connection. If any of<br />
# these addresses could be pinged successfully, the test was<br />
# succesful, i.e. if the ping on the 1st address was successful,the<br />
# 2nd won't be pinged<br />
PlParam "Ping" "8.8.8.8"<br />
PlParam "Ping" "82.165.230.17"<br />
PlParam "pingcmd" "ping -c 1 -q -I tun0 %s"<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Folgender Konfigurationsblock muss ans Ende der Konfigurationsdatei angefügt werden. Es ermöglich olsr die Manipulation der fff-Routingtabelle:<br />
<pre><br />
.<br />
.<br />
.<br />
# Specify the proto tag to be used for routes olsr inserts into kernel<br />
# currently only implemented for linux<br />
# valid values under linux are 1 .. 254<br />
# 1 gets remapped by olsrd to 0 UNSPECIFIED (1 is reserved for ICMP redirects)<br />
# 2 KERNEL routes (not very wise to use)<br />
# 3 BOOT (should in fact not be used by routing daemons)<br />
# 4 STATIC<br />
# 8 .. 15 various routing daemons (gated, zebra, bird, & co)<br />
# (defaults to 0 which gets replaced by an OS-specific default value<br />
# under linux 3 (BOOT) (for backward compatibility)<br />
#<br />
RtProto 8<br />
#<br />
# Specifies the routing Table olsr uses<br />
# RtTable is for host routes, RtTableDefault for the route to the default<br />
# internet gateway (2 in case of IPv6+NIIT) and RtTableTunnel is for<br />
# routes to the ipip tunnels, valid values are 1 to 254<br />
# There is a special parameter "auto" (choose default below)<br />
# (with smartgw: default is 254/223/224)<br />
# (without smartgw: default is 254/254/254, linux main table)<br />
#<br />
RtTable 10<br />
RtTableDefault 10<br />
RtTableTunnel 10<br />
#<br />
# Specifies the policy rule priorities for the three routing tables and<br />
# a special rule for smartgateway routing (see README-Olsr-Extensions)<br />
# Priorities can only be set if three different routing tables are set.<br />
# if set the values must obey to condition<br />
# RtTablePriority < RtTableDefaultOlsrPriority<br />
# < RtTableTunnelPriority < RtTableDefaultPriority.<br />
# There are two special parameters, "auto" (choose fitting to SmartGW<br />
# mode) and "none" (do not set policy rule)<br />
# (with smartgw: default is none/32776/32776/32796)<br />
# (without smartgw: default is none/none/none/none)<br />
#<br />
# RtTablePriority auto<br />
# RtTableDefaultOlsrPriority auto<br />
# RtTableTunnelPriority auto<br />
# RtTableDefaultPriority auto<br />
</pre><br />
<br />
<br />
Das Freifunk Franken intere Routing kann nun getestet werden.<br />
<br />
Zunächst einmal starten wir olsr neu:<br />
<code><br />
/etc/init.d/olsrd restart<br />
</code><br />
<br />
<br />
Die Routinginformationen des olsr-meshes sollten in der fff-Routingtabelle auftauchen:<br />
<code><br />
ip route show table fff<br />
</code><br />
<br />
Exemplarischer Auszug:<br />
<pre><br />
.<br />
.<br />
.<br />
10.50.32.1 via 10.50.32.1 dev ro1 proto gated metric 2 onlink <br />
10.50.32.2 via 10.50.32.2 dev nue1 proto gated metric 2 onlink <br />
10.50.40.0/21 via 10.50.32.1 dev ro1 proto gated metric 2 onlink <br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Eine IP4 aus der Nürnberger Hood (10.50.40.0/21) sollte z.B. von Fürth aus (10.50.32.0/21) erreichbar sein:<br />
<br />
<code><br />
ping 10.50.40.3<br />
</code><br />
<br />
Antwort:<br />
<pre><br />
PING 10.50.40.3 (10.50.40.3) 56(84) bytes of data.<br />
64 bytes from 10.50.40.3: icmp_seq=1 ttl=63 time=42.2 ms<br />
64 bytes from 10.50.40.3: icmp_seq=2 ttl=63 time=42.7 ms<br />
^C<br />
--- 10.50.40.3 ping statistics ---<br />
2 packets transmitted, 2 received, 0% packet loss, time 1000ms<br />
rtt min/avg/max/mdev = 42.279/42.516/42.753/0.237 ms<br />
</pre><br />
<br><br />
=== OpenVPN Start/Stop Automatik ===<br />
OLSR testet mit dem Dynamic Gateway Plugin, ob die Default Route über den OpenVPN Tunnel noch funktioniert, indem regelmässig teilweise mehrere verschiedene Ziele über den Tunnel angepingt werden. Sollte der OpenVPN Tunnel nicht mehr funktionieren, baut OLSR eine neue Default-Route zu einem anderem Gateway auf, über das dann der Internet-Traffic läuft. Beide Default-Routen, die über den OpenVPN Tunnel und die von OLSR, existieren parallel, wobei zunächst weiterhin die OpenVPN Verbindung verwendet wird.<br />
<br />
Da die OpenVPN Verbindung ausgefallen ist, aber trotzdem noch als bevorzugte Default-Route eingetragen ist, ist die Internetanbindung bis die Störung VPN-Server seitig behoben ist, trotzdem nicht verfügbar. <br />
<br />
Für diesen Anwendungsfall wird ein Skript vorgeschlagen, dass die Funktion des OpenVPN Tunnels überwacht und den Tunnel (und die OpenVPN Default-Route) bei Nicht-Funktion abbaut. Um die Funktion zu überprüfen werden in regelmässigen Abständen 2 verschiedene Ziele über den Tunnel angepingt. Scheitert dies, wird der Tunnel für einen gewissen Zeitraum abgebaut, in dem dann stattdessen das OLSR Dynamic Gateway Plugin das Routing übernimmt. Danach wird die Verbindung wieder aufgebaut. Anschliessend wird überprüft, ob der OpenVPN-Tunnel wieder funktioniert. Tut er es nicht, wird er wieder abbgebaut, funktioniert er, bleibt er bis zur Detektion der nächsten Störung als Internetanbindung erhalten.<br />
<br />
Man importiert die Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/auto_start-stop_ovpn.sh -P /usr/local/bin/<br />
</code><br />
<br />
Alternativ kann man statt der Vorlage auch eine leere Datei anlegen:<br />
<code><br />
touch /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
Man macht das Skript ausführbar:<br />
<code><br />
chmod +x /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
<br />
Nun öffnet man die Datei im Editor ...<br />
<code><br />
vi /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
... und füllt sie mit Inhalt oder editiert den importierten Inhalt:<br />
<pre><br />
#!/bin/bash<br />
<br />
IF="tun0" # Interface used for ping<br />
ping1_target="8.8.8.8" # IP no. 1 used for ping<br />
ping2_target="82.165.229.31" # IP no. 2 used for ping<br />
ping_interval="5" # waiting time in-between two pings<br />
switchback_interval="3600" # waiting time for interface to recover before probing again<br />
start_grace="10" # waiting time to allow for tunnel restart<br />
logfile="/dev/null" # logfile for debug<br />
gwsel_lockfile="/tmp/gwsel_lockfile" # lockfile to allow for low bandwidth settings <br />
<br />
openvpn_stop-cmd () { # command used disabling tunnel<br />
#service openvpn stop # ubuntu<br />
/etc/init.d/openvpn stop # debian<br />
#killall openvpn # hardcore<br />
}<br />
<br />
openvpn_start-cmd () { # command used enabling tunnel<br />
#service openvpn start # ubuntu<br />
/etc/init.d/openvpn start # debian<br />
#openvpn /etc/openvpn/*.conf & # hardcore<br />
}<br />
<br />
ping1 () {<br />
echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF" &>> $logfile<br />
ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF &>> $logfile<br />
ping1_ExitCode=$?<br />
echo "$(date): Exit Status: ${ping1_ExitCode}" &>> $logfile<br />
}<br />
<br />
ping2 () {<br />
echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF" &>> $logfile<br />
ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF &>> $logfile<br />
ping2_ExitCode=$?<br />
echo "$(date): Exit Status: ${ping2_ExitCode}" &>> $logfile<br />
}<br />
<br />
<br />
while true<br />
do<br />
# wait for interface build-up, if interface not present<br />
if [ ! -h "/sys/class/net/$IF" ]; then<br />
echo "$(date): Interface $IF not detected. Waiting ${start_grace} seconds." &>> $logfile<br />
sleep ${start_grace}<br />
fi<br />
<br />
# perform ping<br />
ping1<br />
ping2<br />
<br />
# check if ping successful<br />
if ([[ ${ping1_ExitCode} -eq 0 ]] || [[ ${ping2_ExitCode} -eq 0 ]]); then<br />
sleep ${ping_interval}<br />
else<br />
logger -t "$0" ${ping1_target} and ${ping2_target} not reached via interface $IF.<br />
echo "$(date): ${ping1_target} and ${ping2_target} not reached via interface $IF." &>> $logfile<br />
<br />
if [ -h "/sys/class/net/$IF" ]; then<br />
logger -t "$0" Stopping interface $IF.<br />
echo "$(date): Stopping interface $IF." &>> $logfile<br />
openvpn_stop-cmd &>> $logfile<br />
touch ${gwsel_lockfile} &>> $logfile<br />
fi<br />
<br />
sleep ${switchback_interval}<br />
<br />
if [ ! -h "/sys/class/net/$IF" ]; then<br />
logger -t "$0" Restoring interface $IF to probe for recovery.<br />
echo "$(date): Restoring interface $IF to probe for recovery." &>> $logfile<br />
openvpn_start-cmd &>> $logfile<br />
rm -f ${gwsel_lockfile} &>> $logfile<br />
fi<br />
fi<br />
done<br />
</pre><br />
<br />
Hierbei können im Skript folgende Anpassungen vorgenommen werden:<br />
*openvpn_stop-cmd: Der Befehl, mit dem der OpenVPN Tunnel '''abgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ als Prozess gekillt werden.<br />
*openvpn_start-cmd: Der Befehl, mit dem der OpenVPN tunnel '''aufgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ per openvpn Kommandozeilenaufruf gestartet werden.<br />
*IF: Das OpenVPN Tunnel Device. Normalerweise ist das tun0.<br />
*ping1_target,ping2_target: Die IP-Adressen die über das Tunnel-Interface IF angepingt werden, um den Tunnel auf Funktion zu überprüfen. Vorauswahl: Google DNS und Web.de<br />
*ping_interval: Der zeitliche Anstand zwischen zwei Ping-Versuchen. Vorauswahl: 5 Sekunden.<br />
*switchback_interval: Der Zeitraum, den der Tunnel abgebaut bleibt, sollte er als nicht-funktionierend erkannt worden sein. Es wird ein träges Verhalten empfohlen. Vorauswahl: 3600 Sekunden.<br />
*start_grace: Der Zeitraum, der dem Tunnel zum Starten eingeräumt wird. Die Timer-Funktion macht ferner das Skript gegen Restarts des Tunnels unempfindlich.<br />
*logfile: Für Debug Zwecke kann man detaillierte Ausgaben hier in eine Datei umleiten.<br />
*gwsel_lockfile: Setzt bei Störumschaltung ein Lockfile, dass von dem Skript der Gateway Selection (s.o.) ausgewertet werden kann, um eine kleinere Bandbreite für die Dauer der Störumschaltung zu annoncieren. Das Lockfile wird beim Wiederstart des OpenVPN Tunnels gelöscht.<br />
<br />
Das Skript selber kann manuell ...<br />
<code><br />
auto_start-stop_ovpn.sh &<br />
</code><br />
<br />
...und bei jedem Systemstart mit gestartet werden, indem es z.B. in /etc/rc.local ...<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
...wie folgt eingetragen wird:<br />
<pre><br />
.<br />
.<br />
.<br />
#enable tunnel monitoring with 60 seconds delay<br />
(sleep 60; auto_start-stop_ovpn.sh &) &<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Getestet werden kann das Skript z.B., indem man sich alle Default-Routen der fff-Tabelle anzeigen lässt: <br />
<code><br />
watch "ip route show table fff | grep default"<br />
</code><br />
<br />
und parallel dazu auf einer zweiten Shell das openvpn deaktiviert:<br />
<code><br />
killall openvpn<br />
</code><br />
<br />
Es sollte eine neue Default-Route zu einem anderen Gateway aufgebaut werden, über die der Internet-Traffic dann läuft. Die Route über den OpenVPN Tunnel sollte verschwinden. Nach der eingestellten Zeit wird der OpenVPN Tunnel durch das Skript wieder reaktiviert. Danach existieren beide Default-Routen parallel, bis OLSR seine Route automatisch wieder abbaut. Die OpenVPN Default-Route bleibt und ist wieder aktiv.<br />
<br><br />
<br />
=== Priorisieren von OLSR Routen ===<br />
OLSR erstellt die fff-Routingtabelle selbstständig, indem es die Linkqualität anhand von Algorithmen bewertet. Diese Bewertung ist recht volatil, was dazu führen kann, das die von OLSR ausgesuchte Default-Route häufig wechselt. Für die verbundenen Clients wechselt jedes mal die externe Internet IP mit, je nachdem über welches Gateway OLSR den Internet-Traffic gerade abwirft. Bei IP-Wechsel stoppen z.B. Downloads aus dem Internet, stoppen Videos im Abspielen, werden ssh Verbindungen gekappt.<br />
<br />
Um diese Dynamik nicht allzu schnell zu gestalten, empfiehlt es sich OLSR eine oder zwei Default-Routen mitzuteilen, die bevorzugt verwendet werden. Zusätzlich wird NatThreshold, einen Schwellwert den die neue Default-Route besser sein muss als die alte, bevor gewechselt wird, definiert.<br />
<br />
Dies geschieht über Gewichtungsfaktoren in olsrd.conf:<br />
<br />
<code><br />
vi /etc/olsrd/olsrd.conf<br />
</code><br />
<br />
Routen kann man im Abschnitt InterfaceDefaults priorisieren. <br />
Hier können Gewichtungsfaktoren für die GRE-Tunnel zu anderen Gateways eingeführt werden, mit denen die Link-Qualität beeinflusst werden kann:<br />
<pre><br />
.<br />
.<br />
.<br />
# If a certain route should be preferred<br />
# or ignored by the mesh, the Link Quality<br />
# value of a node can be multiplied with a factor<br />
# entered here. In the example the route<br />
# using 192.168.0.1 would rather be ignored.<br />
# A multiplier of 0.5 will result in a small<br />
# (bad) LinkQuality value and a high (bad)<br />
# ETX value.<br />
<br />
# preferred link<br />
LinkQualityMult <tunnel1_ip> 0.99<br />
<br />
# preferred link<br />
LinkQualityMult <tunnel2_ip> 0.99<br />
<br />
# This multiplier applies to all other nodes<br />
LinkQualityMult default 0.7<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Im Beispiel werden alle Routen herabgestuft (Faktor 0.7), mit der Ausnahme derer die über <tunnel1_ip> oder <tunnel2_ip> laufen (Faktor 0.99). <tunnel_ip1> sind dabei die Point-to-Point Partner IPs der GRE Tunnel der jeweiligen Gateways im Freifunk Netz. Die nicht herabgestuften Routen können analog als priorisiert betrachtet werden. Für eine Priorisierung der Route von nue1 zu ro1 wäre die <tunnel1/2_ip> z.B. die 10.50.252.1 (Vgl. [[Portal:Netz]]).<br />
<br />
NatThreshold wird im Hauptabschnitt von olsrd.conf definiert:<br />
<pre><br />
.<br />
.<br />
# If the NAT-Endpoint (the preferred 0/0 HNA emitting node)<br />
# is to be changed, the ETX value of the current 0/0 is<br />
# multiplied with the NatThreshold value before being<br />
# compared to the new one<br />
# The parameter can be a value between 0.1 and 1.0, but<br />
# should be close to 1.0 if changed.<br />
<br />
NatThreshold 0.7<br />
.<br />
.<br />
</pre><br />
<br />
Im Beispiel muss die Linkqualität der neuen Default-Route um 30% besser bewertet als die aktuelle sein, bevor die Default-Route gewechselt wird.<br />
<br />
Die Änderungen werden nach Neustart von OLSR aktiv:<br />
<code><br />
/etc/init.d/olsrd restart<br />
</code><br />
<br><br />
= Einbringen des Gateways in die Hood / Keyserver =<br />
Abschliessend muss das Gateway im Keyserver als Gateway der entsprechenden Hood eingetragen werden. Hierfür benötigt man einen Keyserver-Administrator => [[Server]].<br />
<br />
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.<br />
<br />
Der DHCP-Server sollte als letzter Schritt aktiviert werden (s.o.)<br />
<br><br />
= Transparent Proxy =<br />
Auf dem Gateway kann (aber muss nicht) ein Proxy-Server installiert werden, der Dateien (z.B. Bilder), die schon mal angefragt wurden, nicht aus dem Internet holt, sondern als "lokal" gespeicherte Datei direkt vom Gateway bereitstellt. Die Clients werden dabei über den Proxy gezwungen, d.h. das Gateway leitet die Anfragen pauschal an den Proxy weiter, welcher entscheidet ob der die Anfrage selber bedient oder Gateway-extern anfragt. <br />
<br />
Die Einrichtung eines Proxys ist '''optional''', d.h. der Proxy ist für die Funktion des Gateways nicht notwendig. Proxy-Server reduzieren Antwortzeiten und Traffic für sich '''häufig''' wiederholende Anfragen (z.B. Spiegel Online, Windows Update).<br />
<br />
'''Hinweis''': <br />
Die Einrichtung eines Proxy ist umstritten, da:<br />
* HTTP-Header, wenn auch in geringem Umfang, verändert werden<br />
* Daten, wenn auch nicht direkt einsehbar, auf dem Gateway gespeichert werden<br />
* Daten nicht unmittelbar von der Originalquelle bezogen werden <br />
* Die Effizienzsteigerung gering ist. Nach Auswertung werden ca. 7% aller unverschlüsselten HTTP-Anfragen von dem Gateway direkt beantwortet. Für diese 7% halbiert sich der benötigte Traffic, wobei ein Großteil aller Webseiten heutzutage verschlüsselt wird und z.Zt. 50% des benötigten Traffics Overhead ist. <br />
* Zusätzliche Ressourcen (RAM, Prozessor) auf dem Gateway benötigt werden <br />
<br />
'''Inkompatiblität''': Die Konfiguration funktioniert z.Zt. nicht im Zusammenspiel mit der "OpenVPN Start/Stop Automatik" und dem automatischen OLSR Re-Routing des Default-Gateways (Dynamic Gateway Plugin).<br />
<br><br />
== Installation ==<br />
Installiert wird der de-facto-Standard squid:<br />
<code><br />
apt-get install squid3<br />
</code><br />
<br />
Für die kommende Konfiguration stoppen wir squid wieder:<br />
<code><br />
/etc/init.d/squid3 stop<br />
</code><br />
<br><br />
== Konfiguration ==<br />
Die mit installiere Konfigurationsdatei squid.conf ist sehr umfangreich und bietet eine gute Dokumentationsbasis, ist damit aber auch etwas unhandlich.<br />
<br />
Aus diesem Grund empfiehlt es sich, die Datei umzubenennen:<br />
<code><br />
mv /etc/squid3/squid.conf /etc/squid3/squid.conf.orig<br />
</code><br />
<br />
Wir importieren die Datei von einer Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/squid.conf -P /etc/squid3/<br />
</code><br />
<br />
Alternativ können wir die Datei auch leer erstellen:<br />
<code><br />
touch /etc/squid3/squid.conf<br />
</code><br />
<br />
Danach öffnen wir die Konfigurationsdatei...<br />
<code><br />
vi /etc/squid3/squid.conf<br />
</code><br />
<br />
...und füllen diese mit Inhalt, der allerdings noch auf das Gateway angepasst werden muss:<br />
<pre> <br />
# cache size in MB / no. of subdirectories / no. of subsubdirectories<br />
cache_dir ufs /var/spool/squid3 100 16 256<br />
<br />
#maximum object size in cache (default: 4 MB)<br />
#maximum_object_size 128 MB<br />
maximum_object_size 4 MB<br />
<br />
# Memory used for caching<br />
cache_mem 32 MB<br />
<br />
# No access log<br />
#access_log /var/log/squid3/access.log combined<br />
access_log none<br />
<br />
# Hostname shown in messages<br />
visible_hostname fff<br />
<br />
# Bind Squid to port ... and configure as transparent proxy <br />
http_port 3128 intercept<br />
# In addition a forward proxy is required<br />
http_port 3129<br />
<br />
refresh_pattern ^ftp: 1440 20% 10080<br />
refresh_pattern ^gopher: 1440 0% 1440<br />
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0<br />
refresh_pattern . 0 20% 4320<br />
<br />
# Allow connects from Freifunk Franken network<br />
acl fff src 10.50.0.0/16 <br />
<br />
# DNS by Freifunk-IP of localhost and Google DNS<br />
dns_nameservers 10.50.32.5 8.8.8.8<br />
<br />
# Bind outgoing address to Freifunk-Server IP to allow for VPN Routing <br />
tcp_outgoing_address 10.50.32.5<br />
udp_outgoing_address 10.50.32.5<br />
<br />
# Privacy options <br />
via off<br />
forwarded_for delete<br />
<br />
# standard http anonymizer<br />
request_header_access From deny all<br />
#request_header_access Referer deny all<br />
#request_header_access User-Agent deny all<br />
<br />
## paranoid http anonymizer<br />
#request_header_access Authorization allow all<br />
#request_header_access Proxy-Authorization allow all<br />
#request_header_access Cache-Control allow all<br />
#request_header_access Content-Length allow all<br />
#request_header_access Content-Type allow all<br />
#request_header_access Date allow all<br />
#request_header_access Host allow all<br />
#request_header_access If-Modified-Since allow all<br />
#request_header_access Pragma allow all<br />
#request_header_access Accept allow all<br />
#request_header_access Accept-Charset allow all<br />
#request_header_access Accept-Encoding allow all<br />
#request_header_access Accept-Language allow all<br />
#request_header_access Connection allow all<br />
#request_header_access All deny all<br />
<br />
# Access controls<br />
acl SSL_ports port 443 # https<br />
acl Safe_ports port 80 # http<br />
acl Safe_ports port 21 # ftp<br />
acl Safe_ports port 443 # https<br />
acl Safe_ports port 70 # gopher<br />
acl Safe_ports port 210 # wais<br />
acl Safe_ports port 1025-65535 # unregistered ports<br />
acl Safe_ports port 280 # http-mgmt<br />
acl Safe_ports port 488 # gss-http<br />
acl Safe_ports port 591 # filemaker<br />
acl Safe_ports port 777 # multiling http<br />
<br />
acl CONNECT method CONNECT<br />
http_access deny !Safe_ports<br />
http_access deny CONNECT !SSL_ports<br />
http_access allow localhost manager<br />
http_access deny manager<br />
http_access allow fff<br />
http_access allow localhost<br />
http_access deny all<br />
</pre><br />
<br />
Hier '''müssen''' angepasst werden:<br />
* cache_dir: Die Gesamtgröße des Caches (hier: 100 MByte) muss so bemessen sein, dass auf der Partition auch bei Maximalgröße des Caches noch Speicher frei bleibt. Squid Standardeinstellung ist 100 MB bei 16 Verzeichnissen und jeweils 256 Unterverzeichnissen. Freier Speicherplatz kann mit "df -h" ermittelt werden.<br />
* dns_nameservers: Hier sollten die '''Freifunk-IPv4''' des Gateways (in diesem Beispiel 10.50.32.5) und eine externe IP (hier Google DNS 8.8.8.8) eingetragen werden. Wichtig ist, '''nicht localhost''' einzutragen, da die Anfrage im Zusammenspiel mit der "outgoing address" (s.u.) über die fff-Routingtabelle laufen muss.<br />
* tcp_outgoing_address und udp_outgoing_address: Diese beide Einträge sind elementar wichtig. Zwar funktioniert der Proxy auch ohne, routet aber nicht über das VPN sondern direkt vom Gateway ins Internet. Damit die fff-Routingtabelle verwendet wird, für die als Default-Gateway eine VPN Verbindung eingerichtet ist, tragen wir hier die Freifunk-IP des Gateways ein (10.50.<irgendwas>). In diesem Beispiel ist die Freifunk-IPv4 des Gateways die 10.50.32.5.<br />
* access_log: Das Access log sollte deaktiviert bleiben (access_log none), da es ein lebendiges Beispiel für Vorratsdatenspeicherung ist und die log-Dateien auch sehr schnell, sehr groß werden.<br />
<br />
Danach erstellen wir die Verzeichnisstruktur des Proxy:<br />
<code><br />
squid3 -z<br />
</code><br />
<br />
Jetzt sind wir fast fertig. Wir starten den Proxy:<br />
<code><br />
/etc/init.d/squid3 start<br />
</code><br />
<br />
Anfragen, die auf Port 80 (http) reinkommen, müssen nun noch auf Port 3128 umgeleitet werden. Auf Port 3128 lauscht unser Proxy, http-Anfragen werden quasi transparent (oder zwangsweise) über den Proxy geleitet :<br />
<code><br />
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
</code><br />
<br />
Damit unsere Portumleitung mit jedem Start von Squid eingerichtet und mit jedem Stopp aufgehoben wird, pflegen wir sie (nicht ganz sauber) im squid start/stop Skript mit ein:<br />
<code><br />
vi /etc/init.d/squid3<br />
</code><br />
<br />
und fügen '''zwei''' iptables Einträge nach dem Start und vor dem Stopp von Squid ein:<br />
<pre><br />
.<br />
.<br />
.<br />
start () {<br />
cache_dir=`find_cache_dir cache_dir`<br />
cache_type=`grepconf cache_dir`<br />
<br />
#<br />
# Create run dir (needed for several workers on SMP)<br />
#<br />
create_run_dir<br />
<br />
#<br />
# Create spool dirs if they don't exist.<br />
#<br />
if test -d "$cache_dir" -a ! -d "$cache_dir/00"<br />
then<br />
log_warning_msg "Creating $DESC cache structure"<br />
$DAEMON -z -f $CONFIG<br />
fi<br />
<br />
umask 027<br />
ulimit -n 65535<br />
cd $cache_dir<br />
start-stop-daemon --quiet --start \<br />
--pidfile $PIDFILE \<br />
--exec $DAEMON -- $SQUID_ARGS < /dev/null<br />
# Use as transparent proxy<br />
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
return $?<br />
}<br />
<br />
stop () {<br />
PID=`cat $PIDFILE 2>/dev/null`<br />
# Use as transparent proxy<br />
iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
start-stop-daemon --stop --quiet --pidfile $PIDFILE --exec $DAEMON <br />
#<br />
# Now we have to wait until squid has _really_ stopped.<br />
#<br />
.<br />
.<br />
.<br />
</pre></div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Freifunk-Gateway_aufsetzen&diff=5360
Freifunk-Gateway aufsetzen
2016-01-23T13:32:41Z
<p>Green: /* OpenVPN Start/Stop Automatik */</p>
<hr />
<div>__TOC__<br />
[[Kategorie:Technik]]<br />
<br />
= Preface =<br />
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").<br />
<br />
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.<br />
<br />
Für Rat und Tat empfiehlt sich die Freifunk Franken Development Mailingliste.<br />
<br><br />
= Vorraussetzungen =<br />
* ssh-Zugang zum Server<br />
* Root Zugriff auf den Server. Entweder man ist "root" (Annahme in diesem Artikel) oder man kann Befehle mit "root-Rechten" durch ein vorgesetztes "sudo" ausführen sowie die Möglichkeit auf dem Server Kernelmodule zu laden (kann nicht jeder VServer!) <br />
* Grundlegende Netzwerkkenntnisse<br />
** IPv4 und Netzmaske<br />
** Devices<br />
** Routing (Default Route, Interfaces, Routing-Table) <br />
* Kentnisse <br />
** im Umgang mit Texteditoren (der im Artikel verwendete Editor kann durch beliebig andere ersetzt werden, z.B. durch "nano")<br />
** im Umgang mit der Linux Shell (z.B. Kommandozeilenparameter, Shell-Scripte, Umleitungen)<br />
** in der (selbständigen Nach-)Installation von (fehlenden) Software-Paketen<br />
** im Kompilieren von Software-Quellen<br />
<br><br />
= Referenzen / Andere Freifunk HowTo's =<br />
* http://wiki.freifunk.net/Freifunk_Hamburg/Gateway <br />
* http://wiki.mag.lab.sh/wiki/Freifunk_Fulda/Gateway<br />
<br><br />
= Anforderungen an Gateways =<br />
Die Anforderungen an das Gateway sind an sich niedrig. Wichtig ist, dass die Möglichkeit besteht, eigene Kernel-Module zu laden und das monatliche Traffic-Kontingent nicht zu niedrig ist. Entsprechend sind OpenVZ, Linux-vServer und ähnliche Containerlösungen nicht geeignet.<br />
<br />
Hardware:<br />
* CPU: 1x (64Bit)<br />
* RAM: 256MB .. 1GB<br />
* HDD: > 5 GB<br />
* NIC: 1x<br />
<br />
Software:<br />
* Debian Jessie (8) 64Bit Kernel <br />
* fastd v17<br />
* openvpn<br />
* B.A.T.M.A.N. adv 2013.4.0<br />
* dhcpd<br />
* olsr<br />
* bind9<br />
<br />
Pauschal gibt es keine Mindestanforderungen für den Trafficverbrauch. Es kommt sehr darauf an, wo der Server eingesetzt wird. <br />
'''Momentan suchen wir aber vor allem Server mit einem kostenlosen Traffic von mindestens 10-20 TB/Monat.'''<br />
<br><br />
== Anonymisierung (Störerhaftung) ==<br />
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.<br />
<br />
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. <br />
<br />
Folgende VPN-Anbieter sind zu diesem Zeitpunkt jedoch empfehlenswert:<br />
<br />
* [https://mullvad.net/en/ Mullvad] (Schweden, Niederlande)<br />
** Bis zu drei gleichzeitige Verbindungen<br />
** Kann man anonym mit Bitcoin bezahlen<br />
** Serverauswahl über die ausgelieferte OpenVPN-Konfiguration<br />
*** Server in den Niederlanden sind abends oft stark ausgelastet<br />
**(Gute Erfahrungen in Lübeck)<br />
<br />
* [https://integrityvpn.com/ Integrity VPN] (Schweden, Port80)<br />
** 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.<br />
**Hat eine überaus seriöse Webseite und eine Ltd. erfunden.™<br />
**Hat schon mal was von IPv6 gehört. Nutzt es zurzeit jedoch nur für SEO.<br />
**Blockiert Port 25 derzeit nicht.<br />
**Ist ein ein neuer Anbieter, der _bisher_ unausgelastet wirkt.<br />
** sind derzeit noch nicht nicht overselled und haben ihren Krams scheinbar halbwegs sauber konfiguriert<br />
<br />
* [https://ipredator.se/ Ipredator] (Schweden, Niederlande, Deutschland)<br />
** (Glänzen nicht durch Kompetenz, da sie lange Zeit nur PPTP angeboten haben)<br />
** Mögen schnelle Reconnects nicht -> manchmal muss man OpenVPN ein paar Stunden deaktivieren, bevor es wieder funktioniert.<br />
** Möchten bald auch IPv6 anbieten.<br />
** Angeblich Reseller von relakks<br />
<br />
Ungetestet:<br />
* [https://www.anonine.com/en Anonine VPN] (Portlane)<br />
* [https://privacy.io/ privacy.io] (Portlane)<br />
* [http://prq.se/?p=tunnel&intl=1 prq.se] (Eigenes Netz, teuer)<br />
* [http://arethusa.su/vpn.html Arethusa VPN] (Loggen in Frankreich, andere Server angeblich nicht)<br />
<br />
Einige Freifunknetze mieten auch VMs in Osteuropa. Da die VMs noch nicht an ihre Grezen stößt könnte man diese auch mitnutzen. Ansprechpartner wäre s0ma.<br />
<br><br />
== Anbindung an andere Netze ==<br />
Es gibt drei relativ relevante Netzwerke bei denen es sich lohnt, das lokale Netz damit zu verbinden:<br />
<br />
* InterCity-VPN zwischen den meisten Freifunknetzen<br />
** BGP<br />
** kleine Übsicht der http://www.ddmesh.de/topology/ic-vpn-verbindungen.html<br />
** Mehr Infos http://wiki.freifunk.net/IC-VPN<br />
<br />
* DN42<br />
** BGP<br />
** Experimentelles Darknet zur Erprobung von Routing-Technologien und so weiter, wird privat betrieben. Viel interessantes Zeugs™<br />
** 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.<br />
<br />
* ChaosVPN<br />
** Tinc<br />
** Relativ großes „Darknet“ zwischen vielen Hackerspaces auf der ganzen Welt.<br />
<br><br />
== vServer-Anbieter die empfehlenswert sind ==<br />
* [https://www.de-punkt.de/vserver.html de-punkt] (Databurg, FFM)<br />
** Schneller Speicher, gut bezahlbar, KVM, nur Traffic-Flat™® das übliche.<br />
* [http://www.hetzner.de/hosting/produktmatrix_vserver/vserver-produktmatrix Hetzner] (Falkenstein)<br />
** Bezahlbar, 6.90€/TB Extratraffic, KVM<br />
** Achtung: Die Netzwerkarte der VM ist aus Kompatibilitätsgründen auf e1000 gesetzt. Diese "Netzwerkkarte" kommt nicht mit den vielen UDP-Paketen von fastd zurecht. Deshalb muss man vor Verwendung als Gateway die Netzwerkkarte auf "virtio" stellen.<br />
* [http://colorhost.de/server/vserver/ colorhost] (über 23media, Global Switch, FFM)<br />
* Untersagt Nutzung für Freifunk (http://colorhost.de/server/vserver/kvm/small/)<br />
** Achtung: Nur Xen oder Xen HVM funktionieren<br />
* [http://www.xirra.net/en/v-server/productmatrix/ xirra] (Core-Backbone, NBG)<br />
** KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.<br />
* [http://buyvm.net/ BuyVM]<br />
** 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.<br />
* [http://webhod.de webhod]<br />
** 9,99 € für die kleinste KVM im Monat[https://www.webhod.de/de/vserver/kvm.html]<br />
<br><br />
== Server-Anbieter die '''nicht''' empfehlenswert sind ==<br />
* [http://www.wrzhost.com/ WRZhost]<br />
** 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.<br />
<br />
* [https://www.netcup.de/ netcup]<br />
** V-Server laufen zwar grundsätzlich gut, allerdings halten sie sich nicht an ihre Versprechungen. Server wurde bereits mehrfach gedrosselt obwohl der Traffic weit unter den versprochenen 80 Mbit/s war (zwischen 30 und 40 Mbit/s). Die Drosselung tritt ohne Vorwarnung in Kraft und man kann seinen Server nicht mehr erreichen. Entdrosselung nur auf Nachfrage und dann auch nur mit einigem hin und her.<br />
<br><br />
= Grundinstallation des Servers =<br />
Vom ausgesuchten Hoster lassen wir uns eine aktuelle Linux-Distribution installieren oder ausliefern, wobei sich die Anleitung auf ein Debian 8 / Jessie bezieht.<br />
<br><br />
== Repositories und Update ==<br />
Als erstes werfen wir einen Blick in...<br />
<br />
<code><br />
vi /etc/apt/sources.list<br />
</code><br />
<br />
...und schauen, inwieweit auf die gleichen Software-Repositories verwiesen wird:<br />
<br />
<pre> <br />
deb http://security.debian.org/ jessie/updates main<br />
deb-src http://security.debian.org/ jessie/updates main<br />
<br />
deb http://ftp.de.debian.org/debian/ jessie main contrib non-free<br />
deb-src http://ftp.de.debian.org/debian/ jessie main contrib non-free<br />
<br />
deb http://ftp.de.debian.org/debian/ jessie-updates main<br />
deb-src http://ftp.de.debian.org/debian/ jessie-updates main<br />
<br />
</pre><br />
<br />
Danach bringen wir das System auf einen aktuellen Stand:<br />
<br />
<code><br />
apt-get update<br />
<br />
apt-get upgrade<br />
</code><br />
<br><br />
== Sicherheit ==<br />
Den SSH-Zugang besser schützen durch:<br />
* Änderung des Ports<br />
* login nur mit key<br />
* Siehe [http://www.thomas-krenn.com/de/wiki/Absicherung_eines_Debian_Servers hier] für genaue Anleitung: <br />
<br />
<code><br />
apt-get install fail2ban<br />
</code><br />
<br />
und [http://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban_absichern einrichten]<br />
<br />
So,nun sollte der Server ausreichend abgesichert sein.<br />
<br><br />
== B.A.T.M.A.N. adv 2013.4.0 Kernel-Modul ==<br />
Batman-Adv aus Jessie ist zu neu. Hier muss manuell das alte B.A.T.M.A.N. advanced 2013.4.0 gebaut werden.<br />
<br />
Hierfür benötigen wir minimal die Paketquellen build-essential, linux-headers-amd64 und git:<br />
<br />
<code><br />
apt-get install build-essential linux-headers-amd64 git gnupg-curl<br />
</code><br />
<br />
Die Softwarequellen müssen heruntergeladen...<br />
<code><br />
cd ~<br />
<br />
git clone https://github.com/freifunk-gluon/batman-adv-legacy<br />
<br />
cd batman-adv-legacy<br />
</code><br />
<br />
... und kompiliert und installiert werden:<br />
<br />
<code><br />
make<br />
<br />
make install<br />
</code><br />
<br />
Hinweis: Sollten noch Paketquellen fehlen, wird dies während des Kompilierens gemeldet. Die Software-Quellen müssen nachinstalliert werden und der letzte Kompilierungs- und Installationsschritt so lange wiederholt werden, bis die Software erfolgreich erstellt wurde.<br />
<br />
Nach erfolgreicher Erstellung kann das B.A.T.M.A.N Kernel Modul per modprobe händisch eingebunden werden:<br />
<br />
<code><br />
modprobe batman-adv<br />
</code><br />
<br />
Es sollte dann im Kernel-log ....<br />
<code><br />
dmesg | grep batman_adv<br />
</code><br />
<br />
... mit einem Eintrag gelistet werden:<br />
<pre><br />
batman_adv: B.A.T.M.A.N. advanced 2013.4.0-21-ga854277-dirty (compatibility version 14) loaded<br />
</pre><br />
<br />
Das Kernelmodul von B.A.T.M.A.N. kann dann bei jedem Neustart des Systems geladen werden, indem in die Datei /etc/modules:<br />
<br />
<code><br />
vi /etc/modules<br />
</code><br />
<br />
..der Eintrag "batman-adv" hinzugefügt wird:<br />
<br />
<pre><br />
batman-adv<br />
</pre><br />
<br><br />
== B.A.T.M.A.N adv 2013.4.0 batctl ==<br />
Gleiches gilt für batctl, ein Kommandozeilenprogramm zur B.A.T.M.A.N Konfiguration. Die alte Version 2013.4.0 muss selber gebaut werden, da die Debian 8 / Jessie Paketquellen zu neu sind.<br />
<br />
Herunterladen und Entpacken der Softwarequellen:<br />
<code><br />
cd ~<br />
<br />
wget http://downloads.open-mesh.org/batman/releases/batman-adv-2013.4.0/batctl-2013.4.0.tar.gz<br />
<br />
tar xzf batctl-2013.4.0.tar.gz<br />
<br />
cd batctl-2013.4.0<br />
</code><br />
<br />
Kompilieren und Installieren:<br />
<br />
<code><br />
make<br />
<br />
make install<br />
</code><br />
<br />
Hinweis: Auch hier müssen ggf. fehlende Quellen händisch nachinstalliert und das Kompilieren und Installieren bis zum Erfolg wiederholt werden.<br />
<br><br />
== FastD ==<br />
Die Verbindung zwischen Gateway und Router wird über einen fastd-Tunnel realisiert.<br />
<br />
Hierfür müssen wir ein neues Repository in der Datei /etc/apt/sources.list deklarieren:<br />
<br />
<code><br />
vi /etc/apt/sources.list.d/universe-factory.list<br />
</code><br />
<br />
Dort fügen wir folgendes Repository an:<br />
<br />
<pre><br />
deb http://repo.universe-factory.net/debian/ sid main<br />
deb-src http://repo.universe-factory.net/debian/ sid main<br />
</pre><br />
<br />
Danach die PGP Schlüssel holen:<br />
<code><br />
gpg --keyserver hkps://hkps.pool.sks-keyservers.net --recv-key 16EF3F64CB201D9C<br />
<br />
gpg -a --export 16EF3F64CB201D9C | apt-key add -<br />
</code><br />
<br />
Datenbankupdate der Paketverwaltung:<br />
<code><br />
apt-get update<br />
</code><br />
<br />
Installation von fastd: <br />
<code><br />
apt-get install fastd <br />
</code><br />
<br><br />
<br />
== OpenVPN ==<br />
OpenVPN (falls benötigt) installieren wir mit:<br />
<code><br />
apt-get install openvpn<br />
</code><br />
<br><br />
== DHCP ==<br />
Den DHCP Server installieren wir mit:<br />
<code><br />
apt-get install isc-dhcp-server <br />
</code><br />
<br><br />
== Bind9 ==<br />
Als DNS Server nehmen wir hier den de-facto-Standard bind:<br />
<code><br />
apt-get install bind9 <br />
</code><br />
<br><br />
== OLSR ==<br />
Als Routing-Protokoll, um die einzelnen Hoods später zu einem Freifunk-Franken weit kommunizierenden Netz zu verbinden, wird OLSR installiert:<br />
<br />
<code><br />
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd_0.6.8.1-1_amd64.deb<br />
<br />
dpkg -i olsrd_0.6.8.1-1_amd64.deb<br />
<br />
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd-plugins_0.6.8.1-1_amd64.deb<br />
<br />
dpkg -i olsrd-plugins_0.6.8.1-1_amd64.deb<br />
<br />
</code><br />
<br><br />
= Konfigurieren des Freifunk-Gateways =<br />
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 />
<br><br />
== IPv4 des Gateways, IP-Bereich der Hood und DHCP Range des Gateway==<br />
Für das Gateway suchen wir uns unter [[Portal:Netz]] eine IPv4 Adresse aus dem statischen Range der Hood aus. Für Fürth läuft der Bereich für die statischen Adressen z.B. von 10.50.32.1 - 10.50.32.255. Hiervon suchen wir uns eine '''freie''' Adresse aus, und reservieren diese, indem wir sie weiter unten in die Tabelle der statischen IPs eintragen.<br />
<br />
Die Fürther Hood hat den IP-Bereich 10.50.32.0-10.50.32.255. Als Netzwerk wird dieser Bereich mit 10.50.32.0/21 deklariert, d.h. die ersten 21 Bit der IP identifizieren das Netzwerk "Fürther Hood" und die restlichen 11 Bit stehen zur IP Vergabe zur Verfügung, wobei Anfang (10.50.32.0) und Ende des Bereiches (10.50.39.255) reserviert sind und nicht, weder statisch noch dynamisch durch DHCP, belegt werden dürfen. Eine alternative Schreibweise zu 10.50.32.0/21 ist das Double "Network 10.50.32.0" und "Netmask 255.255.248.0". Ein entsprechender IP-Rechner zur analogen Anwendung in anderen Hoods findet sich z.B. [http://www.heise.de/netze/tools/netzwerkrechner/ hier].<br />
<br />
Ebenso sollte man einen DHCP-Bereich innerhalb des IP-Bereichs der jeweiligen Hood, die der GW bedienen soll, reservieren (d.h. in die oberer Tabelle unter [[Portal:Netz]] eintragen). Jeder DHCP-Server vergibt dynamisch IPv4 Adressen an Clients aus einem vorher definierten Adressbereich. Dieser Adressbereich sollte sich:<br />
* innerhalb des IP-Range der Hood bewegen<br />
* sich nicht mit dem Adressbereich überschneiden, den andere DHCP Server in der Hood verwalten<br />
* sich nicht mit dem Bereich der statischen Adressen der Hood überschneiden<br />
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. Vom gesamten IP-Bereich der Fürther Hood vergibt z.B. das Gateway fff-nue1 die Teilmenge 10.50.35.0 - 10.50.36.255 an Clients und teilt ihnen auf dem Weg auch gleich mit, wie sie Domain-Namen in IPs auflösen und auf welchem Weg sie ins Internet oder in andere Hoods kommen.<br />
<br><br />
== Routing Tabelle für Freifunk ==<br />
Fürs Routing im Freifunk Franken Netz wird eine eigene Routing Tabelle namens "fff" deklariert.<br />
<br />
Dies geschieht indem man in der Datei /etc/iproute2/rt_tables ...<br />
<code><br />
vi /etc/iproute2/rt_tables<br />
</code><br />
<br />
... folgendes am Ende einfügt:<br />
<br />
<pre><br />
10 fff<br />
</pre><br />
<br />
Unsere Freifunk Routing Tabelle lässt sich später durch<br />
<code><br />
ip route show table fff<br />
</code><br />
anzeigen, sobald wir die Tabelle mit Einträgen füllen.<br />
<br><br />
== B.A.T.M.A.N Netzwerk-Interface, fff Routingregeln und -tabelle ==<br />
'''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.<br />
<br />
In der Datei /etc/network/interfaces ...<br />
<br />
<code><br />
vi /etc/network/interfaces<br />
</code><br />
<br />
fügen wir zunächst folgenden Textblock des Gateways "klee" aus der Fürther Hood an:<br />
<br />
<pre><br />
.<br />
.<br />
.<br />
# device: bat0<br />
iface bat0 inet manual<br />
post-up ifconfig $IFACE up<br />
##Einschalten post-up:<br />
# IP des Gateways am B.A.T.M.A.N interface:<br />
post-up ip addr add 10.50.32.5/21 dev $IFACE<br />
# Regeln, wann die fff Routing-Tabelle benutzt werden soll: <br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.0.0.0/8 table fff <br />
post-up ip rule add to 10.0.0.0/8 table fff<br />
# Route in die Fuerther Hood: <br />
post-up ip route add 10.50.32.0/21 dev $IFACE table fff<br />
# Start des DHCP Servers:<br />
post-up invoke-rc.d isc-dhcp-server restart<br />
<br />
##Ausschalten post-down:<br />
# Loeschen von oben definieren Routen, Regeln und Interface: <br />
post-down ip route del 10.50.32.0/21 dev $IFACE table fff<br />
post-down ip rule del from 10.0.0.0/8 table fff<br />
post-down ip rule del to 10.0.0.0/8 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ifconfig $IFACE down<br />
<br />
# VPN Verbindung in die Fuerther Hood<br />
iface ffffuerthVPN inet manual<br />
post-up batctl -m bat0 if add $IFACE<br />
post-up ifconfig $IFACE up<br />
post-up ifup bat0<br />
post-down ifdown bat0<br />
post-down ifconfig $IFACE down<br />
</pre><br />
<br />
In diesem Beispiel sind:<br />
* IP des Gateway/Netzmaske der Fürther Hood: 10.50.32.5/21<br />
* IP des Netzwerks Fürther Hood / Netzmaske der Fürther Hood: 10.50.32.0/21.<br />
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.<br />
<br />
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.).<br />
<br />
Die Regeln definieren, das Traffic der<br />
* aus dem Netzwerk 10.0.0.0/8 kommt<br />
* das Netzwerk 10.0.0.0/8 zum Ziel hat<br />
* oder über die B.A.T.M.A.N Schnittstelle übermittelt wird<br />
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.<br />
<br />
Im post-down Abschnitt werden die vorher definierten Regeln, Interfaces und Routen wieder gelöscht.<br />
<br />
Der untere Abschnitt definiert einen VPN Tunnel in die Fürther Hood. Der Name des Interfaces im Beispiel (ffffuerthVPN) kann individuell neu vergeben werden.<br />
<br><br />
== FastD Start- und Verwaltungsscript ==<br />
Für die Konfiguration von fastd importieren wir eine Datei in ''/etc/fastd'' mit dem Befehl:<br />
<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/fff_beispiel_fastd.sh -P /etc/fastd/<br />
</code><br />
<br />
Alternativ kann das Skript aus einer leeren Datei erstellt werden:<br />
<code><br />
touch /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
danach öffnen wir diese:<br />
<br />
<code><br />
vi /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
und editieren das Skript oder fügen ein Neues ein:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
SERVERNAME="beispiel"<br />
<br />
hood="hoodeintragen"<br />
project="fff"<br />
port=10004<br />
<br />
SERVERNAME="$SERVERNAME.$hood"<br />
<br />
hostname=$SERVERNAME<br />
<br />
if [ ! -d /etc/fastd ]<br />
then<br />
mkdir /etc/fastd<br />
fi<br />
<br />
if [ ! -d /etc/fastd/$project.$hood ]<br />
then<br />
mkdir /etc/fastd/$project.$hood<br />
mkdir /etc/fastd/$project.$hood/peers<br />
<br />
#fastd config<br />
(<br />
echo "# Log warnings and errors to stderr"<br />
echo "log level error;"<br />
echo "# Log everything to a log file"<br />
echo "log to syslog as \"${project}${hood}\" level info;"<br />
echo "# Set the interface name"<br />
echo "interface \"${project}${hood}VPN\";"<br />
echo "# Support xsalsa20 and aes128 encryption methods, prefer xsalsa20"<br />
echo "#method \"xsalsa20-poly1305\";"<br />
echo "#method \"aes128-gcm\";"<br />
echo "method \"null\";"<br />
echo "# Bind to a fixed port, IPv4 only"<br />
echo "bind any:${port};"<br />
echo "# Secret key generated by \"fastd --generate-key\""<br />
echo "secret \"$(fastd --generate-key | grep -i Secret | awk '{print $2}')\";" <br />
echo "# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)" <br />
echo "# (see MTU selection documentation)" <br />
echo "mtu 1426;" <br />
echo "on up \"/etc/fastd/${project}.${hood}/up.sh\";" <br />
echo "on post-down \"/etc/fastd/${project}.${hood}/down.sh\";" <br />
echo "# Include peers from the directory 'peers'" <br />
echo "include peers from \"/etc/fastd/${project}.${hood}/peers\";" <br />
echo "secure handshakes no;"<br />
) >> "/etc/fastd/$project.$hood/$project.$hood.conf"<br />
<br />
#fastd-up<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifdown \$INTERFACE"<br />
) >> /etc/fastd/$project.$hood/down.sh<br />
<br />
chmod +x /etc/fastd/$project.$hood/down.sh<br />
<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifup \$INTERFACE" >> /etc/fastd/$project.$hood/up.sh<br />
) >> /etc/fastd/$project.$hood/up.sh<br />
chmod +x /etc/fastd/$project.$hood/up.sh<br />
fi<br />
<br />
pubkey=$(fastd -c /etc/fastd/$project.$hood/$project.$hood.conf --show-key --machine-readable)<br />
port=$(grep ^bind /etc/fastd/$project.$hood/$project.$hood.conf | cut -d: -f2 | cut -d\; -f1)<br />
<br />
# fire up<br />
if [ "$(/sbin/ifconfig -a | grep -i ethernet | grep ${project}${hood}VPN)" = "" ]<br />
then<br />
/bin/rm /var/run/fastd.$project.$hood.pid<br />
fastd -c /etc/fastd/$project.$hood/$project.$hood.conf -d --pid-file /var/run/fastd.$project.$hood.pid<br />
fi<br />
<br />
# register<br />
wget -T15 -q "http://keyserver.freifunk-franken.de/${project}/?name=$hostname&port=$port&key=$pubkey" -O /tmp/fastd_${project}.${hood}_output <br />
if [ "$?" != "0" ]<br />
then<br />
echo "Update failed"<br />
echo "Exiting, no clean up, no refresh"<br />
exit<br />
fi<br />
<br />
touch /tmp/fastd_${project}.${hood}_starting<br />
<br />
filenames=$(cat /tmp/fastd_${project}.${hood}_output| grep ^#### | sed -e 's/^####//' | sed -e 's/.conf//g')<br />
for file in $filenames<br />
do<br />
grep -A100 ^####$file.conf$ /tmp/fastd_${project}.${hood}_output | grep -v ^####$file.conf$ | grep -m1 ^### -B100 | grep -v ^### | sed 's/ float;/;/g' > "/etc/fastd/$project.$hood/peers/$file"<br />
echo 'float yes;' >> "/etc/fastd/$project.$hood/peers/$file"<br />
done<br />
<br />
#find old peers<br />
OLD=$(find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print)<br />
<br />
if [ -n "${OLD}" ] ; then<br />
echo "Lösche alte:"<br />
echo $OLD<br />
<br />
find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print | xargs /bin/rm /tmp/fastd_${project}.${hood}_starting<br />
fi<br />
<br />
#reload<br />
kill -HUP "$(cat /var/run/fastd.$project.$hood.pid)"<br />
<br />
exit 0<br />
</pre><br />
<br />
Zum Schluss geben wir noch ein<br />
<br />
<code><br />
chmod +x /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
ein, um das Skript ausführbar zu machen.<br />
<br />
Das Skript konfiguriert fastd, indem es<br />
* einen Schlüssel generiert, sollte keiner existieren<br />
* diesen Schlüssel mit dem Keyserver austauscht<br />
* die fastd Konfigurationsdatei anlegt<br />
* den fastd Dämonen startet<br />
<br />
Lediglich der Servername und die Hood müssen oben im Skript händisch angepasst werden. Der Dateiname des Skripts kann individuell angepasst werden.<br />
<br />
Nachdem das Script ausgeführt wurde, sollte man überprüfen ob das Interface in der Konfigurationsdatei unter /etc/fastd/fff.<Hoodname>/fff.<Hoodname>.conf das gleiche ist wie vorher in /etc/network/interfaces festgelegt. Wenn der Name nicht identisch ist (Groß-/Kleinschreibung), werden die Interfaces nicht starten.<br />
<br />
Hinweis: Das Gateway wird standardmässig in die Default-Hood eingebunden. Es wird hier lediglich ein Name für die Konfigurationsdatei und der Gateway Name definiert. Die Zuordnung des Gateways zu der Hood erfolgt später über den KeyXchange (siehe unten).<br />
<br><br />
== IP-Forwarding ==<br />
Um Anfragen, die das Gateway erreichen, weiterzuleiten, muss IP-Forwarding aktiviert werden. <br />
<br />
Manuell geht dies über:<br />
<code><br />
echo "1" > /proc/sys/net/ipv4/ip_forward<br />
<br />
echo "1" > /proc/sys/net/ipv6/conf/default/forwarding<br />
<br />
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding<br />
</code><br />
<br />
Dauerhaft lässt sich IP-Forwarding in /etc/sysctl.conf aktivieren:<br />
<code><br />
vi /etc/sysctl.conf<br />
</code><br />
<br />
.. um dort die Abschnitte einzukommentieren, die das Forwarding steuern:<br />
<pre><br />
.<br />
.<br />
.<br />
# Uncomment the next line to enable packet forwarding for IPv4<br />
net.ipv4.ip_forward=1<br />
<br />
# Uncomment the next line to enable packet forwarding for IPv6<br />
# Enabling this option disables Stateless Address Autoconfiguration<br />
# based on Router Advertisements for this host<br />
net.ipv6.conf.all.forwarding=1<br />
.<br />
.<br />
.<br />
</pre><br />
<br><br />
== Testen von B.A.T.M.A.N, fastd und Autostart ==<br />
Hierfür booten wir das Gateway am besten erst mal neu:<br />
<code><br />
reboot & exit<br />
</code><br />
<br />
und starten das fast.d Startskript manuell: <br />
<code><br />
/etc/fastd/fff_beispiel_fastd.sh &<br />
</code><br />
<br />
Beim Erststart werden Schlüsselpaare generiert und ausgetauscht, es kann also etwas dauern.<br />
<br />
Danach sollte der Aufruf von...<br />
<code><br />
pgrep fastd<br />
</code><br />
... mit der Prozess-ID beantwortet werden: Fastd läuft in dem Fall.<br />
<br />
<br />
Ein Aufruf von ifconfig:<br />
<code><br />
ifconfig<br />
</code><br />
<br />
sollte die neu erstellten Interfaces bat0 und ffffuerthVPN zurückliefern.<br />
Exemplarisch und als Auszug:<br />
<pre><br />
bat0 Link encap:Ethernet HWaddr ea:95:50:07:f7:27 <br />
inet addr:10.50.32.5 Bcast:0.0.0.0 Mask:255.255.248.0<br />
inet6 addr: fe80::e895:50ff:fe07:f727/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:1089992 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:849698 errors:0 dropped:1728 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0 <br />
RX bytes:141311612 (134.7 MiB) TX bytes:1052934594 (1004.1 MiB)<br />
<br />
.<br />
.<br />
.<br />
ffffuerthVPN Link encap:Ethernet HWaddr e6:3b:f3:b7:fc:db <br />
inet6 addr: fe80::e43b:f3ff:feb7:fcdb/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1426 Metric:1<br />
RX packets:32389694 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:2699525 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:500 <br />
RX bytes:4193328694 (3.9 GiB) TX bytes:1384843740 (1.2 GiB)<br />
.<br />
.<br />
.<br />
</pre><br />
Aus dem ifconfig Auszug für bat0 sollte die eingerichtete IP des Gateways und die Netzmaske hervorgehen.<br />
<br />
<br />
Die Abfrage der IP-Regeln:<br />
<code><br />
ip rule<br />
</code><br />
<br />
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):<br />
<pre><br />
32757: from all to 10.0.0.0/8 lookup fff <br />
32758: from 10.0.0.0/8 lookup fff <br />
32759: from all iif bat0 lookup fff <br />
</pre><br />
<br />
Eine Abfrage der fff-Routing Tabelle<br />
<code><br />
ip route show table fff <br />
</code><br />
<br />
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:<br />
<pre><br />
10.50.32.0/21 dev bat0 scope link<br />
</pre><br />
<br />
Ein Aufruf von "batctl o"<br />
<code><br />
batctl o <br />
</code><br />
<br />
ergibt eine Liste der MAC-Adressen von unseren nächsten Nachbarn. Exemplarisch und als Auszug:<br />
<pre><br />
[B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: ffffuerthVPN/e6:3b:f3:b7:fc:db (bat0)]<br />
Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ...<br />
96:43:c4:2e:73:68 0.004s (255) 96:43:c4:2e:73:68 [ffffuerthVPN]: 96:43:c4:2e:73:68 (255)<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
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:<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
Hier spendieren wir einen Eintrag, der fastd mit 10 Sekunden Verzögerung bei jedem Systemstart mitstartet:<br />
<pre><br />
# launch fastd with 10 seconds delay<br />
(sleep 10; sh /etc/fastd/fff_beispiel_fastd.sh) &<br />
</pre><br />
<br />
'''Zusätzlich''' muss ein Cronjob angelegt werden, der das Skript z.B. alle 10 Minuten ausführt:<br />
<code><br />
crontab -e<br />
</code><br />
<br />
Nun folgendes eingeben:<br />
<pre><br />
*/10 * * * * sh /etc/fastd/fff_beispiel_fastd.sh<br />
</pre><br />
<br />
und<br />
<br />
<code><br />
/etc/init.d/cron restart<br />
</code><br />
<br><br />
== OpenVPN-Tunnel einrichten ==<br />
Die Einrichtung eines OpenVPN Tunnels kann von Anbieter zu Anbieter variieren. <br />
Im Laufe der Zeit sollte die Dokumentation so um funktionierende Konfigurationen verschiedener Anbieter erweitert werden.<br />
<br><br />
=== Mullvad ===<br />
Mullvad liefert in der Datei mullvadconfig.zip, die notwendigen Schlüssel (ca.crt, mullvad.crt, mullvad.key) als auch eine Konfigurationsdatei (mullvad_linux.conf) mit, die später angepasst werden muss.<br />
<br />
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:<br />
<br />
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.<br />
<br />
Als unverbindliche Richtschnur für Linux:<br />
<code><br />
scp mullvadconfig.zip root@<ipv4 des Gateways>:/root<br />
</code><br />
<br />
Danach loggen wir uns auf dem Gateway ein und entpacken die Datei (nicht vergessen unzip zu installieren):<br />
<code><br />
ssh root@<ipv4 des Gateways><br />
<br />
unzip mullvadconfig.zip<br />
<br />
cd <Kundennummernverzeichnis><br />
<br />
cp * /etc/openvpn<br />
</code><br />
<br />
''/etc/openvpn/'' sollte mit dem Inhalt des entpackten mullvadconfig.zip Archivs dann so aussehen:<br />
<pre><br />
ca.crt crl.pem mullvad.crt mullvad.key mullvad_linux.conf mullvad-up mullvad_windows.conf.ovpn <br />
</pre><br />
<br />
'''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.<br />
<br />
Wir legen ein benutzerspezifisches start-up Script namens mullvad-up an:<br />
<code><br />
vi /etc/openvpn/mullvad-up<br />
</code><br />
<br />
und füllen sie mit folgendem Inhalt:<br />
<pre><br />
#!/bin/bash<br />
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE<br />
</pre><br />
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.<br />
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.<br />
<br />
Das Skript mullvad-up muss ferner ausführbar sein:<br />
<code><br />
chmod +x /etc/openvpn/mullvad-up<br />
</code><br />
<br />
Dieses spezifische Routing muss zwingend in mullvad_linux.conf eingepflegt werden:<br />
<code><br />
vi /etc/openvpn/mullvad_linux.conf<br />
</code><br />
<br />
und hier die Konfiguration entsprechend geändert werden:<br />
<pre><br />
.<br />
.<br />
.<br />
# Allow calling of built-in executables and user-defined scripts.<br />
script-security 2<br />
<br />
# Parses DHCP options from openvpn to update resolv.conf<br />
#up /etc/openvpn/update-resolv-conf<br />
#down /etc/openvpn/update-resolv-conf<br />
<br />
# Enable Freifunk specific Routing<br />
route-noexec<br />
route-delay 3<br />
route-up /etc/openvpn/mullvad-up<br />
.<br />
.<br />
.<br />
</pre><br />
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.<br />
<br />
Wer möchte, kann in mullvad_linux.conf auch Länder definieren, über die der VPN Traffic laufen soll (Ein- /Auskommentieren).<br />
<br />
Der openvpn Tunnel kann nun testweise gestartet werden:<br />
<code><br />
cd /etc/openvpn<br />
<br />
/usr/sbin/openvpn mullvad_linux.conf &<br />
</code><br />
<br />
und sollte exemplarisch und im Auszug folgendes zurück liefern:<br />
<pre><br />
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<br />
Sun Sep 6 12:45:20 2015 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08<br />
Sun Sep 6 12:45:20 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts<br />
.<br />
.<br />
.<br />
Sun Sep 6 12:45:23 2015 /sbin/ip link set dev tun0 up mtu 1500<br />
Sun Sep 6 12:45:23 2015 /sbin/ip addr add dev tun0 10.114.0.45/16 broadcast 10.114.255.255<br />
Sun Sep 6 12:45:23 2015 /sbin/ip -6 addr add fdef:e287:a479:72::102b/112 dev tun0<br />
Sun Sep 6 12:45:23 2015 /etc/openvpn/mullvad-up tun0 1500 1558 10.114.0.45 255.255.0.0 init<br />
Sun Sep 6 12:45:23 2015 Initialization Sequence Completed<br />
</pre><br />
Wichtig ist hierbei, dass in der vorletztes Zeile unser Freifunk-spezifisches Routing durchgeführt wird.<br />
<br />
Das VPN-Gateway sollte nun als Default Route in der fff-Routingtabelle auftauchen:<br />
<code><br />
ip route show table fff | grep default<br />
</code><br />
<br />
Exemplarisch wäre eine Ausgabe für das Tunnel-Device tun0 und dem VPN-Gateway 10.114.0.1:<br />
<pre><br />
default via 10.114.0.1 dev tun0<br />
</pre><br />
<br />
Auch ein ifconfig Eintrag für das Tunnel Device...<br />
<code><br />
ifconfig<br />
</code><br />
<br />
...sollte jetzt existieren (Exemplarisch und im Auszug):<br />
<pre><br />
.<br />
.<br />
.<br />
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 <br />
inet addr:10.114.0.76 P-t-P:10.114.0.76 Mask:255.255.0.0<br />
inet6 addr: fdad:bdef:735d:72::104a/112 Scope:Global<br />
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1<br />
RX packets:1012476 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:640206 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:100 <br />
RX bytes:1250196616 (1.1 GiB) TX bytes:84979294 (81.0 MiB)<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
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:<br />
<code><br />
vi /etc/rc.local <br />
</code><br />
<br />
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:<br />
<pre><br />
# launch vpn with 5 seconds delay<br />
(sleep 5; /usr/sbin/openvpn /etc/openvpn/mullvad_linux.conf >> /var/log/mullvad_vpn.log &) &<br />
</pre><br />
<br><br />
<br />
=== NordVPN ===<br />
NordVPN liefert die Datei config.zip mit, die für jeden verwendbaren VPN-Server eine seperate Konfigurationsdatei enthält.<br />
<br />
'''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.<br />
<br />
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.<br />
<br />
Als unverbindliche Richtschnur für Linux:<br />
<code><br />
scp config.zip root@<ipv4 des Gateways>:/root<br />
</code><br />
<br />
Und entpacken diese auf dem Gateway:<br />
<code><br />
cd ~<br />
<br />
mkdir nordvpn-configs<br />
<br />
mv config.zip nordvpn-configs<br />
<br />
cd nordvpn-configs<br />
<br />
unzip config.zip<br />
</code><br />
<br />
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.<br />
<br />
Im Beispiel nehmen wir se1.nordvpn.com.udp1194.ovpn und passen Sie zunächst Freifunk-spezifisch an (siehe Aussperr-Hinweis oben):<br />
<br />
<code><br />
vi se1.nordvpn.com.udp1194.ovpn<br />
</code><br />
<br />
Ä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:<br />
<pre><br />
.<br />
.<br />
.<br />
# Provide Username and Password<br />
auth-user-pass /etc/openvpn/nordvpn-pw<br />
.<br />
.<br />
.<br />
# Allow calling of built-in executables and user-defined scripts.<br />
script-security 2<br />
<br />
# Enable Freifunk specific Routing<br />
route-noexec<br />
route-delay 3<br />
route-up /etc/openvpn/nordvpn-up<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
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:<br />
<code><br />
cp se1.nordvpn.com.udp1194.ovpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf<br />
</code><br />
<br />
Hier legen wir noch unser Freifunk Startskript und unsere Password Datei an und machen das Skript ausführbar:<br />
<code><br />
touch /etc/openvpn/nordvpn-up<br />
<br />
touch /etc/openvpn/nordvpn-pw<br />
<br />
chmod +x /etc/openvpn/nordvpn-up<br />
</code><br />
<br />
Man öffnet nordvpn-up...<br />
<code><br />
vi /etc/openvpn/nordvpn-up<br />
</code><br />
<br />
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):<br />
<pre><br />
#!/bin/bash<br />
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE<br />
</pre><br />
<br />
Nun öffnet man nordvpn-pw:<br />
<code><br />
vi /etc/openvpn/nordvpn-pw<br />
</code><br />
<br />
Und legt in der ersten Zeile der Datei seinen NordVPN Usernamen und in der zweiten Zeile sein NordVPN Passwort ab:<br />
<pre><br />
(Username bei NordVPN)<br />
(Password bei NordVPN)<br />
</pre><br />
<br />
Der Tunnel kann nun testweise gestartet werden (hier im Beispiel mit der Konfigurationsdatei se1.nordvpn.com.udp1194.ovpn)<br />
<code><br />
openvpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf &<br />
</code><br />
<br />
Und sollte aufgebaut werden:<br />
<pre><br />
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<br />
.<br />
.<br />
.<br />
Sun Sep 27 09:07:15 2015 /sbin/ip link set dev tun0 up mtu 1500<br />
Sun Sep 27 09:07:15 2015 /sbin/ip addr add dev tun0 local 10.8.8.226 peer 10.8.8.225<br />
Sun Sep 27 09:07:18 2015 Initialization Sequence Completed<br />
</pre><br />
<br />
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:<br />
<code><br />
vi /etc/rc.local <br />
</code><br />
<br />
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:<br />
<pre><br />
# launch vpn with 5 seconds delay<br />
(sleep 5; cd /etc/openvpn ; /usr/sbin/openvpn se1.nordvpn.com.udp1194.ovpn.conf >> /var/log/nordvpn.log &) &<br />
</pre><br />
Die Beispiel-Konfigurationsdatei (se1.nordvpn.com.udp1194.ovpn.conf) muss entsprechend angepasst werden.<br />
<br><br />
== DNS Server ==<br />
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.<br />
<br />
----<br />
<br />
'''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.'''<br />
<br />
----<br />
<br />
Hierfür editieren wir die Datei named.conf.options...<br />
<code><br />
vi /etc/bind/named.conf.options<br />
</code><br />
<br />
...und tragen die DNS Server, die wir anfragen wollen, wenn wir die Information nicht selber haben, als forwarders ein:<br />
<pre><br />
.<br />
.<br />
.<br />
forwarders {<br />
10.50.32.1;<br />
10.50.32.2;<br />
8.8.8.8;<br />
};<br />
allow-query { <br />
127.0.0.1/8; <br />
10.0.0.0/8; <br />
};<br />
.<br />
.<br />
. <br />
</pre><br />
In diesem Fall werden die Freifunk Gateways ro1 (10.50.32.1) und fff-nue1 (10.50.32.2) der Fürther Hood als auch Google DNS (8.8.8.8) als Forwarders definiert. Für andere Hoods muss die lokale Adresse der Freifunk DNS Server unter [[Portal:Netz]] ermittelt werden (z.B. 10.50.48.1 für ro1 in der Ansbacher Hood).<br />
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".<br />
<br />
Neustart des DNS-Servers mit der neuen Konfiguration:<br />
<code><br />
/etc/init.d/bind9 restart<br />
</code><br />
<br />
Testen können wir, indem wir vom DNS Server des Gateways (localhost/127.0.0.1) eine DNS-Auflösung abfragen. <br />
<br />
Ein DNS Resolve für freifunk-franken.de ...<br />
<code><br />
dig @127.0.0.1 freifunk-franken.de<br />
</code><br />
<br />
...sollte von uns selber (Server localhost; 127.0.0.1) beantwortet werden:<br />
<pre><br />
;; global options: +cmd<br />
<br />
;; Got answer:<br />
<br />
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5819<br />
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1 <br />
;; OPT PSEUDOSECTION:<br />
; EDNS: version: 0, flags:; udp: 4096<br />
<br />
;; QUESTION SECTION:<br />
;freifunk-franken.de. IN A<br />
;; ANSWER SECTION:<br />
freifunk-franken.de. 3599 IN A 31.172.113.113 <br />
.<br />
. <br />
.<br />
;; Query time: 117 msec<br />
;; SERVER: 127.0.0.1#53(127.0.0.1)<br />
;; WHEN: Tue Sep 08 14:16:32 EEST 2015<br />
;; MSG SIZE rcvd: 275<br />
</pre><br />
<br><br />
<br />
== B.A.T.M.A.N Gateway Selection ==<br />
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.<br />
<br />
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:<br />
* Bandbreite der Netzanbindung (z.B. 100 Mbit/sec, gesplittet in 50 Mbit/sec up/down)<br />
* 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)<br />
* Erfahrungswerten / eigenes Ermessen<br />
* Bandbreite, bei dem der Gateway Prozessor ausgelastet ist<br />
<br />
Eventuell muss zuerst bc nachinstalliert werden, falls nicht vorhanden:<br />
<code><br />
apt-get install bc<br />
</code><br />
<br />
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.<br />
<br />
Importieren des Skripts aus einer Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/dyn_announce_gw_bw.sh -P /usr/local/bin/<br />
</code><br />
<br />
Alternativ kann das Skript auch als leere Datei erstellt werden:<br />
<code><br />
touch /usr/local/bin/dyn_announce_gw_bw.sh<br />
</code><br />
<br />
Wir machen das Skript ausführbar und öffnen die Datei:<br />
<code><br />
chmod +x /usr/local/bin/dyn_announce_gw_bw.sh<br />
<br />
vi /usr/local/bin/dyn_announce_gw_bw.sh<br />
</code><br />
<br />
Und Füllen dieses mit Inhalt oder editieren den importierten Inhalt:<br />
<pre><br />
#!/bin/bash<br />
gwsel_lockfile="/tmp/gwsel_lockfile" # lockfile to allow for low bandwidth settings <br />
<br />
if [ -z "$1" ]; then<br />
echo<br />
echo "usage: $0 <network-interface> <update_interval [sec]> <total BW up [Mbit/sec]> <total BW down [Mbit/sec]>"<br />
echo<br />
echo "e.g. $0 eth0 60 10 10"<br />
echo<br />
exit<br />
fi<br />
<br />
while true<br />
do<br />
if [ ! -e ${gwsel_lockfile} ]; then # lockfile not present<br />
# Bandwidth currently used (time averaged)<br />
R1=$(cat "/sys/class/net/$1/statistics/rx_bytes")<br />
T1=$(cat "/sys/class/net/$1/statistics/tx_bytes")<br />
sleep "$2"<br />
R2=$(cat "/sys/class/net/$1/statistics/rx_bytes")<br />
T2=$(cat "/sys/class/net/$1/statistics/tx_bytes")<br />
TkbitPS=$(echo "scale=0; ($T2 - $T1) / 1024 * 8 / $2" | bc -l)<br />
RkbitPS=$(echo "scale=0; ($R2 - $R1) / 1024 * 8 / $2" | bc -l)<br />
# echo "BW used -- up $1: $TkbitPS kBit/s; down $1: $RkbitPS kBit/s"<br />
<br />
# Remaining bandwidth available; cut-off negative values<br />
Tavail_kbitPS=$(echo "scale=0; if (($3 * 1024 - $TkbitPS) >0) ($3 * 1024 - $TkbitPS) else 0" | bc -l)<br />
Ravail_kbitPS=$(echo "scale=0; if (($4 * 1024 - $RkbitPS) >0) ($4 * 1024 - $RkbitPS) else 0" | bc -l)<br />
# echo "BW available -- up $1: $Tavail_kbitPS kBit/s; down $1: $Ravail_kbitPS kBit/s"<br />
else # lockfile present<br />
Tavail_kbitPS=0<br />
Ravail_kbitPS=0<br />
sleep "$2"<br />
fi<br />
<br />
for bat in /sys/class/net/bat*; do<br />
iface=${bat##*/}<br />
batctl -m $iface gw_mode server "${Ravail_kbitPS}kbit/${Tavail_kbitPS}kbit" <br />
done<br />
done<br />
</pre><br />
<br />
Das Skript übernimmt als Parameter:<br />
* Netzwerkinterface, das es zu überwachen gilt (i.d.R. eth0)<br />
* 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)<br />
* Upload Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)<br />
* Download Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)<br />
<br />
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 olsr Defaultroute mit geringer Bandbreite verfügbar ist.<br />
<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.:<br />
<code><br />
/usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10<br />
</code><br />
<br />
Um die Gateway Selection beim Systemsstart zu aktivieren, können wir das Skript z.B. in rc.local aufrufen:<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
um dort, leicht zeitverzögert, o.a. Befehl einzupflegen, wobei die Parametrisierung noch Gateway-spezifisch angepasst werden muss:<br />
<pre><br />
.<br />
.<br />
.<br />
#enable batman GW selection with 15 seconds delay<br />
(sleep 15; /usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10) &<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
ACHTUNG! Bei mehreren bat Interfaces (weil man in mehreren Hoods Gateway ist) muss diese Einstellung für jedes Gateway gesetzt werden, hier muss das Script unbedingt überarbeitet werden!<br />
<br />
<pre><br />
batctl -m $batX gw_mode xxmbit/xxmbit<br />
</pre><br />
<br />
und dies für jedes batX Interface. Das Script muss daraufhin noch angepasst werden.<br />
<br />
<br />
auf den Routern kann der vorselektierte Gateway mit <br />
<br />
<code><br />
batctl gwl<br />
</code><br />
<br />
angeguckt werden. Ich vermute das der Gateway mit den Pfeil vorne der vorselektierte Gateway ist, allerdings machen erste beobachtete Daten bisher in meinen Augen noch keinen wirklichen Sinn.<br />
<br><br />
<br />
== DHCP Server ==<br />
Die DHCP Konfiguration kann schon mal vorbereitet werden, sollte aber erst mit als letzter Schritt scharf geschaltet werden. Ein DHCP-Server, der Clients nicht funktionierende DNS-Server oder ein nicht funktionierendes Gateway mitteilt, sperrt diese aus dem Freifunk Netz aus.<br />
<br />
In isc-dhcp-server definieren wir ...<br />
<code><br />
vi /etc/default/isc-dhcp-server<br />
</code><br />
<br />
... das der DHCP Server für das B.A.T.M.A.N Device Anfragen beantworten soll:<br />
<pre><br />
.<br />
.<br />
<br />
INTERFACES="bat0"<br />
.<br />
.<br />
</pre><br />
<br />
Nachfolge Konfiguration wird in auskommentierter Form vorbereitet und sollte erst im letzten Schritt durch Einkommentieren und durch einen Neustart des DHCP Servers...<br />
<code><br />
/etc/init.d/isc-dhcp-server restart<br />
</code><br />
...aktiviert werden.<br />
<br />
Die Konfiguration wird in dhcpd.conf vorgenommen:<br />
<code><br />
vi /etc/dhcp/dhcpd.conf<br />
</code><br />
<br />
und folgender Konfigurationsblock zunächst auskommentiert eingefügt, wobei Gateway und Hood spezifische Änderungen noch eingepflegt werden müssen:<br />
<pre><br />
.<br />
.<br />
.<br />
### Freifunk Franken<br />
#option domain-name "fff.community";<br />
#option domain-name-servers 10.50.16.1;<br />
#authoritative;<br />
### Fuerth<br />
#subnet 10.50.32.0 netmask 255.255.248.0 { # Netzwerk und Netzmaske der Fuerther Hood<br />
# range 10.50.38.0 10.50.39.254; # IP-Range die der DHCP-Server innerhalb der Fuerther Hood verwaltet <br />
# option routers 10.50.32.5; # Default-Gateway, dass Clients mitgeteilt wird <br />
# option domain-name-servers 10.50.32.5, 10.50.32.1; # Name-Server, die Clients mitgeteilt werden<br />
#}<br />
</pre><br />
<br />
Netzwerk und Netzmaske müssen derjenigen der Hood des Gateways entsprechen. Im Beispiel ist dies Fürth, für z.B. Hassberge hieße der Eintrag "subnet 10.50.56.0 netmask 255.255.252.0".<br />
<br />
Der IP-Bereich (Range), die der DHCP-Server in der Hood verwaltet, wurde zuvor unter [[Portal:Netz]] reserviert.<br />
<br />
Unter Routers wird den Clients das Default-Gateway mitgeteilt: Das Gateway, über das Clients das Internet oder eine andere Hood erreichen. In unserem Beispiel routet das aufgesetzte Gateway selber via VPN ins Internet oder via olsr (später) in andere Hoods. Als Default-Gateway wird also die eigene statische IP des Gateways, aus der eigenen Hood, die in [[Portal:Netz]] reserviert wurde, verwendet.<br />
<br />
Ähnlich verhält es sich mit den Nameservern: Auf unserem Gateway wurde ein DNS Server eingerichtet, also kann der domain-name-server unser eigenes Gateway, mit der reservierten statische IP aus der Hood, wie in [[Portal:Netz]], sein. Als Backup empfiehlt sich ein weiterer DNS-Server aus der Hood, in unserem Beispiel ro1 in der Fürther.<br />
<br><br />
<br />
== GRE-Tunnel zu anderen Gateways ==<br />
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]].<br />
<br />
Der GRE-Tunnel wird in /etc/network/interfaces...<br />
<code><br />
vi /etc/network/interfaces<br />
</code><br />
<br />
...mit folgenden noch auf das Gateway anzupassenden Einträgen deklariert:<br />
<pre><br />
auto <tunnel><br />
iface <tunnel> inet static<br />
address <Eigene IPv4 (Freifunk Netz)><br />
pre-up ip -4 tunnel add $IFACE mode gre local <Eigene IPv4 (Internet)> remote <IPv4 des Tunnelpartners (Internet)> ttl 255<br />
#pre-up ip -6 tunnel add $IFACE mode ip6gre local <Eigene IPv6 (Internet)> remote <IPv6 des Tunnelpartners (Internet)> ttl 255<br />
<br />
up ifconfig $IFACE multicast<br />
pointopoint <IPv4 des Tunnelpartners (Freifunk Netz)><br />
post-up iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu<br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.50.0.0/16 table fff<br />
post-up ip rule add to 10.50.0.0/16 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ip rule del from 10.50.0.0/16 table fff<br />
post-down ip rule del to 10.50.0.0/16 table fff<br />
post-down iptables -t mangle -D POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu<br />
post-down iptunnel del $IFACE<br />
</pre><br />
<br />
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.<br />
<br />
'''Beispiel:''' <br />
Um als fff-nue1 einen Tunnel zu ro1 aufzubauen, können die IP-Adressen wie folgt gewählt werden:<br />
<pre><br />
<tunnel> ro1<br />
<Eigene IPv4 (Freifunk Netz)> fff-nue1 10.50.252.1<br />
<IPv4 des Tunnelpartners (Freifunk Netz)> ro1 10.50.252.0<br />
<Eigene IPv4 (Internet)> fff-nue1 31.172.33.99<br />
<IPv4 des Tunnelpartners (Internet)> ro1 176.126.221.7<br />
</pre><br />
<br />
In der Partnerkonfiguration für ro1 werden die Rollen entsprechend vertauscht:<br />
<pre><br />
<tunnel> fff-nue1<br />
<Eigene IPv4 (Freifunk Netz)> ro1 10.50.252.0<br />
<IPv4 des Tunnelpartners (Freifunk Netz)> fff-nue1 10.50.252.1<br />
<Eigene IPv4 (Internet)> ro1 176.126.221.7<br />
<IPv4 des Tunnelpartners (Internet)> fff-nue1 31.172.33.99 <br />
</pre><br />
<br />
Der Tunnel kann über den Aufruf von<br />
<code><br />
ifup <tunnel><br />
</code><br />
...aufgebaut werden, wobei <tunnel> der Name des GRE-Interfaces ist (im Beispiel ro1)<br />
<br />
Nach Aufruf von ifconfig..<br />
<code><br />
ifconfig <br />
</code><br />
sollten wir einen Eintrag für den Tunnel (in diesem Beispiel ro1) vorfinden:<br />
<pre><br />
.<br />
.<br />
.<br />
ro1 Link encap:UNSPEC HWaddr B0-7B-1C-73-30-30-3A-35-00-00-00-00-00-00-00-00 <br />
inet addr:10.50.252.1 P-t-P:10.50.252.0 Mask:255.255.255.255<br />
inet6 addr: fe80::200:5efe:b07b:1c73/64 Scope:Link<br />
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1476 Metric:1<br />
RX packets:160913 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:146654 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0 <br />
RX bytes:66984353 (63.8 MiB) TX bytes:10675001 (10.1 MiB)<br />
.<br />
.<br />
.<br />
</pre><br />
<br><br />
== OLSR ==<br />
=== Basiskonfiguration ===<br />
Mittels OLSR können die Gateways selbstständig Routinginformationen austauschen. Ähnlich wie B.A.T.M.A.N einzelne Router innerhalb einer Hood vermesht (Level 2 Netz), handelt es sich bei olsr um ein mesh zwischen den Gateways (Level 3). Es ermöglicht ein Freifunk Franken internes Routing: z.B. kann eine beliebige IPv4 aus der Nürnberger Hood aus der Fürth Hood heraus erreicht werden.<br />
<br />
Vorlagen können unter Sicherung der Originaldateien wie folgt importiert werden:<br />
<code><br />
mv /etc/default/olsrd /etc/default/olsrd.orig<br />
<br />
mv /etc/olsrd/olsrd.conf /etc/olsrd/olsrd.conf.orig<br />
<br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd -P /etc/default/<br />
<br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd.conf -P /etc/olsrd/<br />
</code><br />
<br />
Zunächst zeigen wir die Interfaces an, unter dem wir olsr Routing Informationen austauschen:<br />
<code><br />
vi /etc/default/olsrd<br />
</code><br />
<br />
Im Beispiel wird über die 2 GRE-Tunnel nue1 und ro1 ausgetauscht, dies muss entsprechend der GRE-Tunnel Konfiguration angepasst werden: <br />
<pre><br />
.<br />
.<br />
#<br />
# Uncomment the next line run olsrd automatically at startup<br />
#<br />
START_OLSRD="YES"<br />
<br />
#<br />
# Uncomment the next line to force-configure the wifi interface to be setup<br />
# for ad-hoc mode using the /usr/sbin/olsrd-adhoc-setup script whenever olsrd<br />
# is started.<br />
#<br />
SETUP_ADHOC="NO"<br />
.<br />
.<br />
.<br />
#<br />
# Specify the network interfaces that olsrd will run on, this will most likely<br />
# be your wifi interface.<br />
#<br />
MESH_IF="nue1 ro1" <br />
.<br />
.<br />
</pre><br />
<br />
<br />
Weiter wird dann hier ...<br />
<code><br />
vi /etc/olsrd/olsrd.conf<br />
</code><br />
... konfiguriert. <br />
Da unser Beispiel-Gateway ins Netz der Fürther Hood eingebunden ist, teilen wir dies andern Gateways über den Eintrag 10.50.32.0/21 mit:<br />
<pre><br />
.<br />
.<br />
.<br />
# HNA IPv4 routes<br />
# syntax: netaddr netmask<br />
# Example Internet gateway:<br />
# 0.0.0.0 0.0.0.0<br />
<br />
Hna4<br />
{<br />
# Internet gateway:<br />
# 0.0.0.0 0.0.0.0<br />
# more entries can be added:<br />
# 192.168.1.0 255.255.255.0<br />
10.50.32.0/21<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Hier wird das olsr Webinterface auf port 8080 konfiguriert:<br />
<br />
<pre><br />
.<br />
.<br />
.<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
# defaults to 1978<br />
PlParam "Port" "8080"<br />
# if you dont set these, the default is to listen only on the loopback device<br />
#PlParam "Host" "80.23.53.22"<br />
#PlParam "Net" "10.0.0.0 255.0.0.0"<br />
PlParam "Net" "0.0.0.0 0.0.0.0"<br />
#PlParam "Host" "127.0.0.1"<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Ferner wird der VPN-Tunnel (hier tun0) per persönlich angepasstem ping Kommando auf sein Funktion hin überwacht. Sollte der VPN-Tunnel ausfallen, ermöglicht olsr im Zusammenspiel mit der Routing Priorisierung (s.u) und der OpenVPN Start-/Stop Automatik (s.u.) ein automatisches Re-Routing:<br />
<pre><br />
.<br />
.<br />
.<br />
LoadPlugin "olsrd_dyn_gw.so.0.5"<br />
{<br />
# Here parameters are set to be sent to the<br />
# plugin. Theese are on the form "key" "value".<br />
# Parameters ofcause, differs from plugin to plugin.<br />
# Consult the documentation of your plugin for details.<br />
<br />
# Example: dyn_gw params<br />
<br />
# how often to check for Internet connectivity<br />
# defaults to 5 secs<br />
PlParam "Interval" "5"<br />
<br />
# if one or more IPv4 addresses are given, do a ping on these in<br />
# descending order to validate that there is not only an entry in<br />
# routing table, but also a real internet connection. If any of<br />
# these addresses could be pinged successfully, the test was<br />
# succesful, i.e. if the ping on the 1st address was successful,the<br />
# 2nd won't be pinged<br />
PlParam "Ping" "8.8.8.8"<br />
PlParam "Ping" "82.165.230.17"<br />
PlParam "pingcmd" "ping -c 1 -q -I tun0 %s"<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Folgender Konfigurationsblock muss ans Ende der Konfigurationsdatei angefügt werden. Es ermöglich olsr die Manipulation der fff-Routingtabelle:<br />
<pre><br />
.<br />
.<br />
.<br />
# Specify the proto tag to be used for routes olsr inserts into kernel<br />
# currently only implemented for linux<br />
# valid values under linux are 1 .. 254<br />
# 1 gets remapped by olsrd to 0 UNSPECIFIED (1 is reserved for ICMP redirects)<br />
# 2 KERNEL routes (not very wise to use)<br />
# 3 BOOT (should in fact not be used by routing daemons)<br />
# 4 STATIC<br />
# 8 .. 15 various routing daemons (gated, zebra, bird, & co)<br />
# (defaults to 0 which gets replaced by an OS-specific default value<br />
# under linux 3 (BOOT) (for backward compatibility)<br />
#<br />
RtProto 8<br />
#<br />
# Specifies the routing Table olsr uses<br />
# RtTable is for host routes, RtTableDefault for the route to the default<br />
# internet gateway (2 in case of IPv6+NIIT) and RtTableTunnel is for<br />
# routes to the ipip tunnels, valid values are 1 to 254<br />
# There is a special parameter "auto" (choose default below)<br />
# (with smartgw: default is 254/223/224)<br />
# (without smartgw: default is 254/254/254, linux main table)<br />
#<br />
RtTable 10<br />
RtTableDefault 10<br />
RtTableTunnel 10<br />
#<br />
# Specifies the policy rule priorities for the three routing tables and<br />
# a special rule for smartgateway routing (see README-Olsr-Extensions)<br />
# Priorities can only be set if three different routing tables are set.<br />
# if set the values must obey to condition<br />
# RtTablePriority < RtTableDefaultOlsrPriority<br />
# < RtTableTunnelPriority < RtTableDefaultPriority.<br />
# There are two special parameters, "auto" (choose fitting to SmartGW<br />
# mode) and "none" (do not set policy rule)<br />
# (with smartgw: default is none/32776/32776/32796)<br />
# (without smartgw: default is none/none/none/none)<br />
#<br />
# RtTablePriority auto<br />
# RtTableDefaultOlsrPriority auto<br />
# RtTableTunnelPriority auto<br />
# RtTableDefaultPriority auto<br />
</pre><br />
<br />
<br />
Das Freifunk Franken intere Routing kann nun getestet werden.<br />
<br />
Zunächst einmal starten wir olsr neu:<br />
<code><br />
/etc/init.d/olsrd restart<br />
</code><br />
<br />
<br />
Die Routinginformationen des olsr-meshes sollten in der fff-Routingtabelle auftauchen:<br />
<code><br />
ip route show table fff<br />
</code><br />
<br />
Exemplarischer Auszug:<br />
<pre><br />
.<br />
.<br />
.<br />
10.50.32.1 via 10.50.32.1 dev ro1 proto gated metric 2 onlink <br />
10.50.32.2 via 10.50.32.2 dev nue1 proto gated metric 2 onlink <br />
10.50.40.0/21 via 10.50.32.1 dev ro1 proto gated metric 2 onlink <br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Eine IP4 aus der Nürnberger Hood (10.50.40.0/21) sollte z.B. von Fürth aus (10.50.32.0/21) erreichbar sein:<br />
<br />
<code><br />
ping 10.50.40.3<br />
</code><br />
<br />
Antwort:<br />
<pre><br />
PING 10.50.40.3 (10.50.40.3) 56(84) bytes of data.<br />
64 bytes from 10.50.40.3: icmp_seq=1 ttl=63 time=42.2 ms<br />
64 bytes from 10.50.40.3: icmp_seq=2 ttl=63 time=42.7 ms<br />
^C<br />
--- 10.50.40.3 ping statistics ---<br />
2 packets transmitted, 2 received, 0% packet loss, time 1000ms<br />
rtt min/avg/max/mdev = 42.279/42.516/42.753/0.237 ms<br />
</pre><br />
<br><br />
=== OpenVPN Start/Stop Automatik ===<br />
OLSR testet mit dem Dynamic Gateway Plugin, ob die Default Route über den OpenVPN Tunnel noch funktioniert, indem regelmässig teilweise mehrere verschiedene Ziele über den Tunnel angepingt werden. Sollte der OpenVPN Tunnel nicht mehr funktionieren, baut OLSR eine neue Default-Route zu einem anderem Gateway auf, über das dann der Internet-Traffic läuft. Beide Default-Routen, die über den OpenVPN Tunnel und die von OLSR, existieren parallel, wobei zunächst weiterhin die OpenVPN Verbindung verwendet wird.<br />
<br />
Da die OpenVPN Verbindung ausgefallen ist, aber trotzdem noch als bevorzugte Default-Route eingetragen ist, ist die Internetanbindung bis die Störung VPN-Server seitig behoben ist, trotzdem nicht verfügbar. <br />
<br />
Für diesen Anwendungsfall wird ein Skript vorgeschlagen, dass die Funktion des OpenVPN Tunnels überwacht und den Tunnel (und die OpenVPN Default-Route) bei Nicht-Funktion abbaut. Um die Funktion zu überprüfen werden in regelmässigen Abständen 2 verschiedene Ziele über den Tunnel angepingt. Scheitert dies, wird der Tunnel für einen gewissen Zeitraum abgebaut, in dem dann stattdessen das OLSR Dynamic Gateway Plugin das Routing übernimmt. Danach wird die Verbindung wieder aufgebaut. Anschliessend wird überprüft, ob der OpenVPN-Tunnel wieder funktioniert. Tut er es nicht, wird er wieder abbgebaut, funktioniert er, bleibt er bis zur Detektion der nächsten Störung als Internetanbindung erhalten.<br />
<br />
Man importiert die Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/auto_start-stop_ovpn.sh -P /usr/local/bin/<br />
</code><br />
<br />
Alternativ kann man statt der Vorlage auch eine leere Datei anlegen:<br />
<code><br />
touch /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
Man macht das Skript ausführbar:<br />
<code><br />
chmod +x /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
<br />
Nun öffnet man die Datei im Editor ...<br />
<code><br />
vi /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
... und füllt sie mit Inhalt oder editiert den importierten Inhalt:<br />
<pre><br />
#!/bin/bash<br />
<br />
IF="tun0" # Interface used for ping<br />
ping1_target="8.8.8.8" # IP no. 1 used for ping<br />
ping2_target="82.165.229.31" # IP no. 2 used for ping<br />
ping_interval="5" # waiting time in-between two pings<br />
switchback_interval="3600" # waiting time for interface to recover before probing again<br />
start_grace="10" # waiting time to allow for tunnel restart<br />
logfile="/dev/null" # logfile for debug<br />
gwsel_lockfile="/tmp/gwsel_lockfile" # lockfile to allow for low bandwidth settings <br />
<br />
openvpn_stop-cmd () { # command used disabling tunnel<br />
#service openvpn stop # ubuntu<br />
/etc/init.d/openvpn stop # debian<br />
#killall openvpn # hardcore<br />
}<br />
<br />
openvpn_start-cmd () { # command used enabling tunnel<br />
#service openvpn start # ubuntu<br />
/etc/init.d/openvpn start # debian<br />
#openvpn /etc/openvpn/*.conf & # hardcore<br />
}<br />
<br />
ping1 () {<br />
echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF" &>> $logfile<br />
ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF &>> $logfile<br />
ping1_ExitCode=$?<br />
echo "$(date): Exit Status: ${ping1_ExitCode}" &>> $logfile<br />
}<br />
<br />
ping2 () {<br />
echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF" &>> $logfile<br />
ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF &>> $logfile<br />
ping2_ExitCode=$?<br />
echo "$(date): Exit Status: ${ping2_ExitCode}" &>> $logfile<br />
}<br />
<br />
<br />
while true<br />
do<br />
# wait for interface build-up, if interface not present<br />
if [ ! -h "/sys/class/net/$IF" ]; then<br />
echo "$(date): Interface $IF not detected. Waiting ${start_grace} seconds." &>> $logfile<br />
sleep ${start_grace}<br />
fi<br />
<br />
# perform ping<br />
ping1<br />
ping2<br />
<br />
# check if ping successful<br />
if ([[ ${ping1_ExitCode} -eq 0 ]] || [[ ${ping2_ExitCode} -eq 0 ]]); then<br />
sleep ${ping_interval}<br />
else<br />
logger -t "$0" ${ping1_target} and ${ping2_target} not reached via interface $IF.<br />
echo "$(date): ${ping1_target} and ${ping2_target} not reached via interface $IF." &>> $logfile<br />
touch ${gwsel_lockfile} &>> $logfile<br />
<br />
if [ -h "/sys/class/net/$IF" ]; then<br />
logger -t "$0" Stopping interface $IF.<br />
echo "$(date): Stopping interface $IF." &>> $logfile<br />
openvpn_stop-cmd &>> $logfile<br />
fi<br />
<br />
sleep ${switchback_interval}<br />
rm -f ${gwsel_lockfile} &>> $logfile<br />
<br />
if [ ! -h "/sys/class/net/$IF" ]; then<br />
logger -t "$0" Restoring interface $IF to probe for recovery.<br />
echo "$(date): Restoring interface $IF to probe for recovery." &>> $logfile<br />
openvpn_start-cmd &>> $logfile<br />
fi<br />
fi<br />
done<br />
</pre><br />
<br />
Hierbei können im Skript folgende Anpassungen vorgenommen werden:<br />
*openvpn_stop-cmd: Der Befehl, mit dem der OpenVPN Tunnel '''abgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ als Prozess gekillt werden.<br />
*openvpn_start-cmd: Der Befehl, mit dem der OpenVPN tunnel '''aufgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ per openvpn Kommandozeilenaufruf gestartet werden.<br />
*IF: Das OpenVPN Tunnel Device. Normalerweise ist das tun0.<br />
*ping1_target,ping2_target: Die IP-Adressen die über das Tunnel-Interface IF angepingt werden, um den Tunnel auf Funktion zu überprüfen. Vorauswahl: Google DNS und Web.de<br />
*ping_interval: Der zeitliche Anstand zwischen zwei Ping-Versuchen. Vorauswahl: 5 Sekunden.<br />
*switchback_interval: Der Zeitraum, den der Tunnel abgebaut bleibt, sollte er als nicht-funktionierend erkannt worden sein. Es wird ein träges Verhalten empfohlen. Vorauswahl: 3600 Sekunden.<br />
*start_grace: Der Zeitraum, der dem Tunnel zum Starten eingeräumt wird. Die Timer-Funktion macht ferner das Skript gegen Restarts des Tunnels unempfindlich.<br />
*logfile: Für Debug Zwecke kann man detaillierte Ausgaben hier in eine Datei umleiten.<br />
*gwsel_lockfile: Setzt bei Störumschaltung ein Lockfile, dass von dem Skript der Gateway Selection (s.o.) ausgewertet werden kann, um eine kleinere Bandbreite für die Dauer der Störumschaltung zu annoncieren. Das Lockfile wird beim Wiederstart des OpenVPN Tunnels gelöscht.<br />
<br />
Das Skript selber kann manuell ...<br />
<code><br />
auto_start-stop_ovpn.sh &<br />
</code><br />
<br />
...und bei jedem Systemstart mit gestartet werden, indem es z.B. in /etc/rc.local ...<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
...wie folgt eingetragen wird:<br />
<pre><br />
.<br />
.<br />
.<br />
#enable tunnel monitoring with 60 seconds delay<br />
(sleep 60; auto_start-stop_ovpn.sh &) &<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Getestet werden kann das Skript z.B., indem man sich alle Default-Routen der fff-Tabelle anzeigen lässt: <br />
<code><br />
watch "ip route show table fff | grep default"<br />
</code><br />
<br />
und parallel dazu auf einer zweiten Shell das openvpn deaktiviert:<br />
<code><br />
killall openvpn<br />
</code><br />
<br />
Es sollte eine neue Default-Route zu einem anderen Gateway aufgebaut werden, über die der Internet-Traffic dann läuft. Die Route über den OpenVPN Tunnel sollte verschwinden. Nach der eingestellten Zeit wird der OpenVPN Tunnel durch das Skript wieder reaktiviert. Danach existieren beide Default-Routen parallel, bis OLSR seine Route automatisch wieder abbaut. Die OpenVPN Default-Route bleibt und ist wieder aktiv.<br />
<br><br />
<br />
=== Priorisieren von OLSR Routen ===<br />
OLSR erstellt die fff-Routingtabelle selbstständig, indem es die Linkqualität anhand von Algorithmen bewertet. Diese Bewertung ist recht volatil, was dazu führen kann, das die von OLSR ausgesuchte Default-Route häufig wechselt. Für die verbundenen Clients wechselt jedes mal die externe Internet IP mit, je nachdem über welches Gateway OLSR den Internet-Traffic gerade abwirft. Bei IP-Wechsel stoppen z.B. Downloads aus dem Internet, stoppen Videos im Abspielen, werden ssh Verbindungen gekappt.<br />
<br />
Um diese Dynamik nicht allzu schnell zu gestalten, empfiehlt es sich OLSR eine oder zwei Default-Routen mitzuteilen, die bevorzugt verwendet werden. Zusätzlich wird NatThreshold, einen Schwellwert den die neue Default-Route besser sein muss als die alte, bevor gewechselt wird, definiert.<br />
<br />
Dies geschieht über Gewichtungsfaktoren in olsrd.conf:<br />
<br />
<code><br />
vi /etc/olsrd/olsrd.conf<br />
</code><br />
<br />
Routen kann man im Abschnitt InterfaceDefaults priorisieren. <br />
Hier können Gewichtungsfaktoren für die GRE-Tunnel zu anderen Gateways eingeführt werden, mit denen die Link-Qualität beeinflusst werden kann:<br />
<pre><br />
.<br />
.<br />
.<br />
# If a certain route should be preferred<br />
# or ignored by the mesh, the Link Quality<br />
# value of a node can be multiplied with a factor<br />
# entered here. In the example the route<br />
# using 192.168.0.1 would rather be ignored.<br />
# A multiplier of 0.5 will result in a small<br />
# (bad) LinkQuality value and a high (bad)<br />
# ETX value.<br />
<br />
# preferred link<br />
LinkQualityMult <tunnel1_ip> 0.99<br />
<br />
# preferred link<br />
LinkQualityMult <tunnel2_ip> 0.99<br />
<br />
# This multiplier applies to all other nodes<br />
LinkQualityMult default 0.7<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Im Beispiel werden alle Routen herabgestuft (Faktor 0.7), mit der Ausnahme derer die über <tunnel1_ip> oder <tunnel2_ip> laufen (Faktor 0.99). <tunnel_ip1> sind dabei die Point-to-Point Partner IPs der GRE Tunnel der jeweiligen Gateways im Freifunk Netz. Die nicht herabgestuften Routen können analog als priorisiert betrachtet werden. Für eine Priorisierung der Route von nue1 zu ro1 wäre die <tunnel1/2_ip> z.B. die 10.50.252.1 (Vgl. [[Portal:Netz]]).<br />
<br />
NatThreshold wird im Hauptabschnitt von olsrd.conf definiert:<br />
<pre><br />
.<br />
.<br />
# If the NAT-Endpoint (the preferred 0/0 HNA emitting node)<br />
# is to be changed, the ETX value of the current 0/0 is<br />
# multiplied with the NatThreshold value before being<br />
# compared to the new one<br />
# The parameter can be a value between 0.1 and 1.0, but<br />
# should be close to 1.0 if changed.<br />
<br />
NatThreshold 0.7<br />
.<br />
.<br />
</pre><br />
<br />
Im Beispiel muss die Linkqualität der neuen Default-Route um 30% besser bewertet als die aktuelle sein, bevor die Default-Route gewechselt wird.<br />
<br />
Die Änderungen werden nach Neustart von OLSR aktiv:<br />
<code><br />
/etc/init.d/olsrd restart<br />
</code><br />
<br><br />
= Einbringen des Gateways in die Hood / Keyserver =<br />
Abschliessend muss das Gateway im Keyserver als Gateway der entsprechenden Hood eingetragen werden. Hierfür benötigt man einen Keyserver-Administrator => [[Server]].<br />
<br />
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.<br />
<br />
Der DHCP-Server sollte als letzter Schritt aktiviert werden (s.o.)<br />
<br><br />
= Transparent Proxy =<br />
Auf dem Gateway kann (aber muss nicht) ein Proxy-Server installiert werden, der Dateien (z.B. Bilder), die schon mal angefragt wurden, nicht aus dem Internet holt, sondern als "lokal" gespeicherte Datei direkt vom Gateway bereitstellt. Die Clients werden dabei über den Proxy gezwungen, d.h. das Gateway leitet die Anfragen pauschal an den Proxy weiter, welcher entscheidet ob der die Anfrage selber bedient oder Gateway-extern anfragt. <br />
<br />
Die Einrichtung eines Proxys ist '''optional''', d.h. der Proxy ist für die Funktion des Gateways nicht notwendig. Proxy-Server reduzieren Antwortzeiten und Traffic für sich '''häufig''' wiederholende Anfragen (z.B. Spiegel Online, Windows Update).<br />
<br />
'''Hinweis''': <br />
Die Einrichtung eines Proxy ist umstritten, da:<br />
* HTTP-Header, wenn auch in geringem Umfang, verändert werden<br />
* Daten, wenn auch nicht direkt einsehbar, auf dem Gateway gespeichert werden<br />
* Daten nicht unmittelbar von der Originalquelle bezogen werden <br />
* Die Effizienzsteigerung gering ist. Nach Auswertung werden ca. 7% aller unverschlüsselten HTTP-Anfragen von dem Gateway direkt beantwortet. Für diese 7% halbiert sich der benötigte Traffic, wobei ein Großteil aller Webseiten heutzutage verschlüsselt wird und z.Zt. 50% des benötigten Traffics Overhead ist. <br />
* Zusätzliche Ressourcen (RAM, Prozessor) auf dem Gateway benötigt werden <br />
<br />
'''Inkompatiblität''': Die Konfiguration funktioniert z.Zt. nicht im Zusammenspiel mit der "OpenVPN Start/Stop Automatik" und dem automatischen OLSR Re-Routing des Default-Gateways (Dynamic Gateway Plugin).<br />
<br><br />
== Installation ==<br />
Installiert wird der de-facto-Standard squid:<br />
<code><br />
apt-get install squid3<br />
</code><br />
<br />
Für die kommende Konfiguration stoppen wir squid wieder:<br />
<code><br />
/etc/init.d/squid3 stop<br />
</code><br />
<br><br />
== Konfiguration ==<br />
Die mit installiere Konfigurationsdatei squid.conf ist sehr umfangreich und bietet eine gute Dokumentationsbasis, ist damit aber auch etwas unhandlich.<br />
<br />
Aus diesem Grund empfiehlt es sich, die Datei umzubenennen:<br />
<code><br />
mv /etc/squid3/squid.conf /etc/squid3/squid.conf.orig<br />
</code><br />
<br />
Wir importieren die Datei von einer Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/squid.conf -P /etc/squid3/<br />
</code><br />
<br />
Alternativ können wir die Datei auch leer erstellen:<br />
<code><br />
touch /etc/squid3/squid.conf<br />
</code><br />
<br />
Danach öffnen wir die Konfigurationsdatei...<br />
<code><br />
vi /etc/squid3/squid.conf<br />
</code><br />
<br />
...und füllen diese mit Inhalt, der allerdings noch auf das Gateway angepasst werden muss:<br />
<pre> <br />
# cache size in MB / no. of subdirectories / no. of subsubdirectories<br />
cache_dir ufs /var/spool/squid3 100 16 256<br />
<br />
#maximum object size in cache (default: 4 MB)<br />
#maximum_object_size 128 MB<br />
maximum_object_size 4 MB<br />
<br />
# Memory used for caching<br />
cache_mem 32 MB<br />
<br />
# No access log<br />
#access_log /var/log/squid3/access.log combined<br />
access_log none<br />
<br />
# Hostname shown in messages<br />
visible_hostname fff<br />
<br />
# Bind Squid to port ... and configure as transparent proxy <br />
http_port 3128 intercept<br />
# In addition a forward proxy is required<br />
http_port 3129<br />
<br />
refresh_pattern ^ftp: 1440 20% 10080<br />
refresh_pattern ^gopher: 1440 0% 1440<br />
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0<br />
refresh_pattern . 0 20% 4320<br />
<br />
# Allow connects from Freifunk Franken network<br />
acl fff src 10.50.0.0/16 <br />
<br />
# DNS by Freifunk-IP of localhost and Google DNS<br />
dns_nameservers 10.50.32.5 8.8.8.8<br />
<br />
# Bind outgoing address to Freifunk-Server IP to allow for VPN Routing <br />
tcp_outgoing_address 10.50.32.5<br />
udp_outgoing_address 10.50.32.5<br />
<br />
# Privacy options <br />
via off<br />
forwarded_for delete<br />
<br />
# standard http anonymizer<br />
request_header_access From deny all<br />
#request_header_access Referer deny all<br />
#request_header_access User-Agent deny all<br />
<br />
## paranoid http anonymizer<br />
#request_header_access Authorization allow all<br />
#request_header_access Proxy-Authorization allow all<br />
#request_header_access Cache-Control allow all<br />
#request_header_access Content-Length allow all<br />
#request_header_access Content-Type allow all<br />
#request_header_access Date allow all<br />
#request_header_access Host allow all<br />
#request_header_access If-Modified-Since allow all<br />
#request_header_access Pragma allow all<br />
#request_header_access Accept allow all<br />
#request_header_access Accept-Charset allow all<br />
#request_header_access Accept-Encoding allow all<br />
#request_header_access Accept-Language allow all<br />
#request_header_access Connection allow all<br />
#request_header_access All deny all<br />
<br />
# Access controls<br />
acl SSL_ports port 443 # https<br />
acl Safe_ports port 80 # http<br />
acl Safe_ports port 21 # ftp<br />
acl Safe_ports port 443 # https<br />
acl Safe_ports port 70 # gopher<br />
acl Safe_ports port 210 # wais<br />
acl Safe_ports port 1025-65535 # unregistered ports<br />
acl Safe_ports port 280 # http-mgmt<br />
acl Safe_ports port 488 # gss-http<br />
acl Safe_ports port 591 # filemaker<br />
acl Safe_ports port 777 # multiling http<br />
<br />
acl CONNECT method CONNECT<br />
http_access deny !Safe_ports<br />
http_access deny CONNECT !SSL_ports<br />
http_access allow localhost manager<br />
http_access deny manager<br />
http_access allow fff<br />
http_access allow localhost<br />
http_access deny all<br />
</pre><br />
<br />
Hier '''müssen''' angepasst werden:<br />
* cache_dir: Die Gesamtgröße des Caches (hier: 100 MByte) muss so bemessen sein, dass auf der Partition auch bei Maximalgröße des Caches noch Speicher frei bleibt. Squid Standardeinstellung ist 100 MB bei 16 Verzeichnissen und jeweils 256 Unterverzeichnissen. Freier Speicherplatz kann mit "df -h" ermittelt werden.<br />
* dns_nameservers: Hier sollten die '''Freifunk-IPv4''' des Gateways (in diesem Beispiel 10.50.32.5) und eine externe IP (hier Google DNS 8.8.8.8) eingetragen werden. Wichtig ist, '''nicht localhost''' einzutragen, da die Anfrage im Zusammenspiel mit der "outgoing address" (s.u.) über die fff-Routingtabelle laufen muss.<br />
* tcp_outgoing_address und udp_outgoing_address: Diese beide Einträge sind elementar wichtig. Zwar funktioniert der Proxy auch ohne, routet aber nicht über das VPN sondern direkt vom Gateway ins Internet. Damit die fff-Routingtabelle verwendet wird, für die als Default-Gateway eine VPN Verbindung eingerichtet ist, tragen wir hier die Freifunk-IP des Gateways ein (10.50.<irgendwas>). In diesem Beispiel ist die Freifunk-IPv4 des Gateways die 10.50.32.5.<br />
* access_log: Das Access log sollte deaktiviert bleiben (access_log none), da es ein lebendiges Beispiel für Vorratsdatenspeicherung ist und die log-Dateien auch sehr schnell, sehr groß werden.<br />
<br />
Danach erstellen wir die Verzeichnisstruktur des Proxy:<br />
<code><br />
squid3 -z<br />
</code><br />
<br />
Jetzt sind wir fast fertig. Wir starten den Proxy:<br />
<code><br />
/etc/init.d/squid3 start<br />
</code><br />
<br />
Anfragen, die auf Port 80 (http) reinkommen, müssen nun noch auf Port 3128 umgeleitet werden. Auf Port 3128 lauscht unser Proxy, http-Anfragen werden quasi transparent (oder zwangsweise) über den Proxy geleitet :<br />
<code><br />
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
</code><br />
<br />
Damit unsere Portumleitung mit jedem Start von Squid eingerichtet und mit jedem Stopp aufgehoben wird, pflegen wir sie (nicht ganz sauber) im squid start/stop Skript mit ein:<br />
<code><br />
vi /etc/init.d/squid3<br />
</code><br />
<br />
und fügen '''zwei''' iptables Einträge nach dem Start und vor dem Stopp von Squid ein:<br />
<pre><br />
.<br />
.<br />
.<br />
start () {<br />
cache_dir=`find_cache_dir cache_dir`<br />
cache_type=`grepconf cache_dir`<br />
<br />
#<br />
# Create run dir (needed for several workers on SMP)<br />
#<br />
create_run_dir<br />
<br />
#<br />
# Create spool dirs if they don't exist.<br />
#<br />
if test -d "$cache_dir" -a ! -d "$cache_dir/00"<br />
then<br />
log_warning_msg "Creating $DESC cache structure"<br />
$DAEMON -z -f $CONFIG<br />
fi<br />
<br />
umask 027<br />
ulimit -n 65535<br />
cd $cache_dir<br />
start-stop-daemon --quiet --start \<br />
--pidfile $PIDFILE \<br />
--exec $DAEMON -- $SQUID_ARGS < /dev/null<br />
# Use as transparent proxy<br />
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
return $?<br />
}<br />
<br />
stop () {<br />
PID=`cat $PIDFILE 2>/dev/null`<br />
# Use as transparent proxy<br />
iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
start-stop-daemon --stop --quiet --pidfile $PIDFILE --exec $DAEMON <br />
#<br />
# Now we have to wait until squid has _really_ stopped.<br />
#<br />
.<br />
.<br />
.<br />
</pre></div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Freifunk-Gateway_aufsetzen&diff=5359
Freifunk-Gateway aufsetzen
2016-01-23T13:11:17Z
<p>Green: /* OpenVPN Start/Stop Automatik */</p>
<hr />
<div>__TOC__<br />
[[Kategorie:Technik]]<br />
<br />
= Preface =<br />
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").<br />
<br />
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.<br />
<br />
Für Rat und Tat empfiehlt sich die Freifunk Franken Development Mailingliste.<br />
<br><br />
= Vorraussetzungen =<br />
* ssh-Zugang zum Server<br />
* Root Zugriff auf den Server. Entweder man ist "root" (Annahme in diesem Artikel) oder man kann Befehle mit "root-Rechten" durch ein vorgesetztes "sudo" ausführen sowie die Möglichkeit auf dem Server Kernelmodule zu laden (kann nicht jeder VServer!) <br />
* Grundlegende Netzwerkkenntnisse<br />
** IPv4 und Netzmaske<br />
** Devices<br />
** Routing (Default Route, Interfaces, Routing-Table) <br />
* Kentnisse <br />
** im Umgang mit Texteditoren (der im Artikel verwendete Editor kann durch beliebig andere ersetzt werden, z.B. durch "nano")<br />
** im Umgang mit der Linux Shell (z.B. Kommandozeilenparameter, Shell-Scripte, Umleitungen)<br />
** in der (selbständigen Nach-)Installation von (fehlenden) Software-Paketen<br />
** im Kompilieren von Software-Quellen<br />
<br><br />
= Referenzen / Andere Freifunk HowTo's =<br />
* http://wiki.freifunk.net/Freifunk_Hamburg/Gateway <br />
* http://wiki.mag.lab.sh/wiki/Freifunk_Fulda/Gateway<br />
<br><br />
= Anforderungen an Gateways =<br />
Die Anforderungen an das Gateway sind an sich niedrig. Wichtig ist, dass die Möglichkeit besteht, eigene Kernel-Module zu laden und das monatliche Traffic-Kontingent nicht zu niedrig ist. Entsprechend sind OpenVZ, Linux-vServer und ähnliche Containerlösungen nicht geeignet.<br />
<br />
Hardware:<br />
* CPU: 1x (64Bit)<br />
* RAM: 256MB .. 1GB<br />
* HDD: > 5 GB<br />
* NIC: 1x<br />
<br />
Software:<br />
* Debian Jessie (8) 64Bit Kernel <br />
* fastd v17<br />
* openvpn<br />
* B.A.T.M.A.N. adv 2013.4.0<br />
* dhcpd<br />
* olsr<br />
* bind9<br />
<br />
Pauschal gibt es keine Mindestanforderungen für den Trafficverbrauch. Es kommt sehr darauf an, wo der Server eingesetzt wird. <br />
'''Momentan suchen wir aber vor allem Server mit einem kostenlosen Traffic von mindestens 10-20 TB/Monat.'''<br />
<br><br />
== Anonymisierung (Störerhaftung) ==<br />
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.<br />
<br />
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. <br />
<br />
Folgende VPN-Anbieter sind zu diesem Zeitpunkt jedoch empfehlenswert:<br />
<br />
* [https://mullvad.net/en/ Mullvad] (Schweden, Niederlande)<br />
** Bis zu drei gleichzeitige Verbindungen<br />
** Kann man anonym mit Bitcoin bezahlen<br />
** Serverauswahl über die ausgelieferte OpenVPN-Konfiguration<br />
*** Server in den Niederlanden sind abends oft stark ausgelastet<br />
**(Gute Erfahrungen in Lübeck)<br />
<br />
* [https://integrityvpn.com/ Integrity VPN] (Schweden, Port80)<br />
** 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.<br />
**Hat eine überaus seriöse Webseite und eine Ltd. erfunden.™<br />
**Hat schon mal was von IPv6 gehört. Nutzt es zurzeit jedoch nur für SEO.<br />
**Blockiert Port 25 derzeit nicht.<br />
**Ist ein ein neuer Anbieter, der _bisher_ unausgelastet wirkt.<br />
** sind derzeit noch nicht nicht overselled und haben ihren Krams scheinbar halbwegs sauber konfiguriert<br />
<br />
* [https://ipredator.se/ Ipredator] (Schweden, Niederlande, Deutschland)<br />
** (Glänzen nicht durch Kompetenz, da sie lange Zeit nur PPTP angeboten haben)<br />
** Mögen schnelle Reconnects nicht -> manchmal muss man OpenVPN ein paar Stunden deaktivieren, bevor es wieder funktioniert.<br />
** Möchten bald auch IPv6 anbieten.<br />
** Angeblich Reseller von relakks<br />
<br />
Ungetestet:<br />
* [https://www.anonine.com/en Anonine VPN] (Portlane)<br />
* [https://privacy.io/ privacy.io] (Portlane)<br />
* [http://prq.se/?p=tunnel&intl=1 prq.se] (Eigenes Netz, teuer)<br />
* [http://arethusa.su/vpn.html Arethusa VPN] (Loggen in Frankreich, andere Server angeblich nicht)<br />
<br />
Einige Freifunknetze mieten auch VMs in Osteuropa. Da die VMs noch nicht an ihre Grezen stößt könnte man diese auch mitnutzen. Ansprechpartner wäre s0ma.<br />
<br><br />
== Anbindung an andere Netze ==<br />
Es gibt drei relativ relevante Netzwerke bei denen es sich lohnt, das lokale Netz damit zu verbinden:<br />
<br />
* InterCity-VPN zwischen den meisten Freifunknetzen<br />
** BGP<br />
** kleine Übsicht der http://www.ddmesh.de/topology/ic-vpn-verbindungen.html<br />
** Mehr Infos http://wiki.freifunk.net/IC-VPN<br />
<br />
* DN42<br />
** BGP<br />
** Experimentelles Darknet zur Erprobung von Routing-Technologien und so weiter, wird privat betrieben. Viel interessantes Zeugs™<br />
** 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.<br />
<br />
* ChaosVPN<br />
** Tinc<br />
** Relativ großes „Darknet“ zwischen vielen Hackerspaces auf der ganzen Welt.<br />
<br><br />
== vServer-Anbieter die empfehlenswert sind ==<br />
* [https://www.de-punkt.de/vserver.html de-punkt] (Databurg, FFM)<br />
** Schneller Speicher, gut bezahlbar, KVM, nur Traffic-Flat™® das übliche.<br />
* [http://www.hetzner.de/hosting/produktmatrix_vserver/vserver-produktmatrix Hetzner] (Falkenstein)<br />
** Bezahlbar, 6.90€/TB Extratraffic, KVM<br />
** Achtung: Die Netzwerkarte der VM ist aus Kompatibilitätsgründen auf e1000 gesetzt. Diese "Netzwerkkarte" kommt nicht mit den vielen UDP-Paketen von fastd zurecht. Deshalb muss man vor Verwendung als Gateway die Netzwerkkarte auf "virtio" stellen.<br />
* [http://colorhost.de/server/vserver/ colorhost] (über 23media, Global Switch, FFM)<br />
* Untersagt Nutzung für Freifunk (http://colorhost.de/server/vserver/kvm/small/)<br />
** Achtung: Nur Xen oder Xen HVM funktionieren<br />
* [http://www.xirra.net/en/v-server/productmatrix/ xirra] (Core-Backbone, NBG)<br />
** KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.<br />
* [http://buyvm.net/ BuyVM]<br />
** 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.<br />
* [http://webhod.de webhod]<br />
** 9,99 € für die kleinste KVM im Monat[https://www.webhod.de/de/vserver/kvm.html]<br />
<br><br />
== Server-Anbieter die '''nicht''' empfehlenswert sind ==<br />
* [http://www.wrzhost.com/ WRZhost]<br />
** 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.<br />
<br />
* [https://www.netcup.de/ netcup]<br />
** V-Server laufen zwar grundsätzlich gut, allerdings halten sie sich nicht an ihre Versprechungen. Server wurde bereits mehrfach gedrosselt obwohl der Traffic weit unter den versprochenen 80 Mbit/s war (zwischen 30 und 40 Mbit/s). Die Drosselung tritt ohne Vorwarnung in Kraft und man kann seinen Server nicht mehr erreichen. Entdrosselung nur auf Nachfrage und dann auch nur mit einigem hin und her.<br />
<br><br />
= Grundinstallation des Servers =<br />
Vom ausgesuchten Hoster lassen wir uns eine aktuelle Linux-Distribution installieren oder ausliefern, wobei sich die Anleitung auf ein Debian 8 / Jessie bezieht.<br />
<br><br />
== Repositories und Update ==<br />
Als erstes werfen wir einen Blick in...<br />
<br />
<code><br />
vi /etc/apt/sources.list<br />
</code><br />
<br />
...und schauen, inwieweit auf die gleichen Software-Repositories verwiesen wird:<br />
<br />
<pre> <br />
deb http://security.debian.org/ jessie/updates main<br />
deb-src http://security.debian.org/ jessie/updates main<br />
<br />
deb http://ftp.de.debian.org/debian/ jessie main contrib non-free<br />
deb-src http://ftp.de.debian.org/debian/ jessie main contrib non-free<br />
<br />
deb http://ftp.de.debian.org/debian/ jessie-updates main<br />
deb-src http://ftp.de.debian.org/debian/ jessie-updates main<br />
<br />
</pre><br />
<br />
Danach bringen wir das System auf einen aktuellen Stand:<br />
<br />
<code><br />
apt-get update<br />
<br />
apt-get upgrade<br />
</code><br />
<br><br />
== Sicherheit ==<br />
Den SSH-Zugang besser schützen durch:<br />
* Änderung des Ports<br />
* login nur mit key<br />
* Siehe [http://www.thomas-krenn.com/de/wiki/Absicherung_eines_Debian_Servers hier] für genaue Anleitung: <br />
<br />
<code><br />
apt-get install fail2ban<br />
</code><br />
<br />
und [http://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban_absichern einrichten]<br />
<br />
So,nun sollte der Server ausreichend abgesichert sein.<br />
<br><br />
== B.A.T.M.A.N. adv 2013.4.0 Kernel-Modul ==<br />
Batman-Adv aus Jessie ist zu neu. Hier muss manuell das alte B.A.T.M.A.N. advanced 2013.4.0 gebaut werden.<br />
<br />
Hierfür benötigen wir minimal die Paketquellen build-essential, linux-headers-amd64 und git:<br />
<br />
<code><br />
apt-get install build-essential linux-headers-amd64 git gnupg-curl<br />
</code><br />
<br />
Die Softwarequellen müssen heruntergeladen...<br />
<code><br />
cd ~<br />
<br />
git clone https://github.com/freifunk-gluon/batman-adv-legacy<br />
<br />
cd batman-adv-legacy<br />
</code><br />
<br />
... und kompiliert und installiert werden:<br />
<br />
<code><br />
make<br />
<br />
make install<br />
</code><br />
<br />
Hinweis: Sollten noch Paketquellen fehlen, wird dies während des Kompilierens gemeldet. Die Software-Quellen müssen nachinstalliert werden und der letzte Kompilierungs- und Installationsschritt so lange wiederholt werden, bis die Software erfolgreich erstellt wurde.<br />
<br />
Nach erfolgreicher Erstellung kann das B.A.T.M.A.N Kernel Modul per modprobe händisch eingebunden werden:<br />
<br />
<code><br />
modprobe batman-adv<br />
</code><br />
<br />
Es sollte dann im Kernel-log ....<br />
<code><br />
dmesg | grep batman_adv<br />
</code><br />
<br />
... mit einem Eintrag gelistet werden:<br />
<pre><br />
batman_adv: B.A.T.M.A.N. advanced 2013.4.0-21-ga854277-dirty (compatibility version 14) loaded<br />
</pre><br />
<br />
Das Kernelmodul von B.A.T.M.A.N. kann dann bei jedem Neustart des Systems geladen werden, indem in die Datei /etc/modules:<br />
<br />
<code><br />
vi /etc/modules<br />
</code><br />
<br />
..der Eintrag "batman-adv" hinzugefügt wird:<br />
<br />
<pre><br />
batman-adv<br />
</pre><br />
<br><br />
== B.A.T.M.A.N adv 2013.4.0 batctl ==<br />
Gleiches gilt für batctl, ein Kommandozeilenprogramm zur B.A.T.M.A.N Konfiguration. Die alte Version 2013.4.0 muss selber gebaut werden, da die Debian 8 / Jessie Paketquellen zu neu sind.<br />
<br />
Herunterladen und Entpacken der Softwarequellen:<br />
<code><br />
cd ~<br />
<br />
wget http://downloads.open-mesh.org/batman/releases/batman-adv-2013.4.0/batctl-2013.4.0.tar.gz<br />
<br />
tar xzf batctl-2013.4.0.tar.gz<br />
<br />
cd batctl-2013.4.0<br />
</code><br />
<br />
Kompilieren und Installieren:<br />
<br />
<code><br />
make<br />
<br />
make install<br />
</code><br />
<br />
Hinweis: Auch hier müssen ggf. fehlende Quellen händisch nachinstalliert und das Kompilieren und Installieren bis zum Erfolg wiederholt werden.<br />
<br><br />
== FastD ==<br />
Die Verbindung zwischen Gateway und Router wird über einen fastd-Tunnel realisiert.<br />
<br />
Hierfür müssen wir ein neues Repository in der Datei /etc/apt/sources.list deklarieren:<br />
<br />
<code><br />
vi /etc/apt/sources.list.d/universe-factory.list<br />
</code><br />
<br />
Dort fügen wir folgendes Repository an:<br />
<br />
<pre><br />
deb http://repo.universe-factory.net/debian/ sid main<br />
deb-src http://repo.universe-factory.net/debian/ sid main<br />
</pre><br />
<br />
Danach die PGP Schlüssel holen:<br />
<code><br />
gpg --keyserver hkps://hkps.pool.sks-keyservers.net --recv-key 16EF3F64CB201D9C<br />
<br />
gpg -a --export 16EF3F64CB201D9C | apt-key add -<br />
</code><br />
<br />
Datenbankupdate der Paketverwaltung:<br />
<code><br />
apt-get update<br />
</code><br />
<br />
Installation von fastd: <br />
<code><br />
apt-get install fastd <br />
</code><br />
<br><br />
<br />
== OpenVPN ==<br />
OpenVPN (falls benötigt) installieren wir mit:<br />
<code><br />
apt-get install openvpn<br />
</code><br />
<br><br />
== DHCP ==<br />
Den DHCP Server installieren wir mit:<br />
<code><br />
apt-get install isc-dhcp-server <br />
</code><br />
<br><br />
== Bind9 ==<br />
Als DNS Server nehmen wir hier den de-facto-Standard bind:<br />
<code><br />
apt-get install bind9 <br />
</code><br />
<br><br />
== OLSR ==<br />
Als Routing-Protokoll, um die einzelnen Hoods später zu einem Freifunk-Franken weit kommunizierenden Netz zu verbinden, wird OLSR installiert:<br />
<br />
<code><br />
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd_0.6.8.1-1_amd64.deb<br />
<br />
dpkg -i olsrd_0.6.8.1-1_amd64.deb<br />
<br />
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd-plugins_0.6.8.1-1_amd64.deb<br />
<br />
dpkg -i olsrd-plugins_0.6.8.1-1_amd64.deb<br />
<br />
</code><br />
<br><br />
= Konfigurieren des Freifunk-Gateways =<br />
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 />
<br><br />
== IPv4 des Gateways, IP-Bereich der Hood und DHCP Range des Gateway==<br />
Für das Gateway suchen wir uns unter [[Portal:Netz]] eine IPv4 Adresse aus dem statischen Range der Hood aus. Für Fürth läuft der Bereich für die statischen Adressen z.B. von 10.50.32.1 - 10.50.32.255. Hiervon suchen wir uns eine '''freie''' Adresse aus, und reservieren diese, indem wir sie weiter unten in die Tabelle der statischen IPs eintragen.<br />
<br />
Die Fürther Hood hat den IP-Bereich 10.50.32.0-10.50.32.255. Als Netzwerk wird dieser Bereich mit 10.50.32.0/21 deklariert, d.h. die ersten 21 Bit der IP identifizieren das Netzwerk "Fürther Hood" und die restlichen 11 Bit stehen zur IP Vergabe zur Verfügung, wobei Anfang (10.50.32.0) und Ende des Bereiches (10.50.39.255) reserviert sind und nicht, weder statisch noch dynamisch durch DHCP, belegt werden dürfen. Eine alternative Schreibweise zu 10.50.32.0/21 ist das Double "Network 10.50.32.0" und "Netmask 255.255.248.0". Ein entsprechender IP-Rechner zur analogen Anwendung in anderen Hoods findet sich z.B. [http://www.heise.de/netze/tools/netzwerkrechner/ hier].<br />
<br />
Ebenso sollte man einen DHCP-Bereich innerhalb des IP-Bereichs der jeweiligen Hood, die der GW bedienen soll, reservieren (d.h. in die oberer Tabelle unter [[Portal:Netz]] eintragen). Jeder DHCP-Server vergibt dynamisch IPv4 Adressen an Clients aus einem vorher definierten Adressbereich. Dieser Adressbereich sollte sich:<br />
* innerhalb des IP-Range der Hood bewegen<br />
* sich nicht mit dem Adressbereich überschneiden, den andere DHCP Server in der Hood verwalten<br />
* sich nicht mit dem Bereich der statischen Adressen der Hood überschneiden<br />
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. Vom gesamten IP-Bereich der Fürther Hood vergibt z.B. das Gateway fff-nue1 die Teilmenge 10.50.35.0 - 10.50.36.255 an Clients und teilt ihnen auf dem Weg auch gleich mit, wie sie Domain-Namen in IPs auflösen und auf welchem Weg sie ins Internet oder in andere Hoods kommen.<br />
<br><br />
== Routing Tabelle für Freifunk ==<br />
Fürs Routing im Freifunk Franken Netz wird eine eigene Routing Tabelle namens "fff" deklariert.<br />
<br />
Dies geschieht indem man in der Datei /etc/iproute2/rt_tables ...<br />
<code><br />
vi /etc/iproute2/rt_tables<br />
</code><br />
<br />
... folgendes am Ende einfügt:<br />
<br />
<pre><br />
10 fff<br />
</pre><br />
<br />
Unsere Freifunk Routing Tabelle lässt sich später durch<br />
<code><br />
ip route show table fff<br />
</code><br />
anzeigen, sobald wir die Tabelle mit Einträgen füllen.<br />
<br><br />
== B.A.T.M.A.N Netzwerk-Interface, fff Routingregeln und -tabelle ==<br />
'''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.<br />
<br />
In der Datei /etc/network/interfaces ...<br />
<br />
<code><br />
vi /etc/network/interfaces<br />
</code><br />
<br />
fügen wir zunächst folgenden Textblock des Gateways "klee" aus der Fürther Hood an:<br />
<br />
<pre><br />
.<br />
.<br />
.<br />
# device: bat0<br />
iface bat0 inet manual<br />
post-up ifconfig $IFACE up<br />
##Einschalten post-up:<br />
# IP des Gateways am B.A.T.M.A.N interface:<br />
post-up ip addr add 10.50.32.5/21 dev $IFACE<br />
# Regeln, wann die fff Routing-Tabelle benutzt werden soll: <br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.0.0.0/8 table fff <br />
post-up ip rule add to 10.0.0.0/8 table fff<br />
# Route in die Fuerther Hood: <br />
post-up ip route add 10.50.32.0/21 dev $IFACE table fff<br />
# Start des DHCP Servers:<br />
post-up invoke-rc.d isc-dhcp-server restart<br />
<br />
##Ausschalten post-down:<br />
# Loeschen von oben definieren Routen, Regeln und Interface: <br />
post-down ip route del 10.50.32.0/21 dev $IFACE table fff<br />
post-down ip rule del from 10.0.0.0/8 table fff<br />
post-down ip rule del to 10.0.0.0/8 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ifconfig $IFACE down<br />
<br />
# VPN Verbindung in die Fuerther Hood<br />
iface ffffuerthVPN inet manual<br />
post-up batctl -m bat0 if add $IFACE<br />
post-up ifconfig $IFACE up<br />
post-up ifup bat0<br />
post-down ifdown bat0<br />
post-down ifconfig $IFACE down<br />
</pre><br />
<br />
In diesem Beispiel sind:<br />
* IP des Gateway/Netzmaske der Fürther Hood: 10.50.32.5/21<br />
* IP des Netzwerks Fürther Hood / Netzmaske der Fürther Hood: 10.50.32.0/21.<br />
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.<br />
<br />
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.).<br />
<br />
Die Regeln definieren, das Traffic der<br />
* aus dem Netzwerk 10.0.0.0/8 kommt<br />
* das Netzwerk 10.0.0.0/8 zum Ziel hat<br />
* oder über die B.A.T.M.A.N Schnittstelle übermittelt wird<br />
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.<br />
<br />
Im post-down Abschnitt werden die vorher definierten Regeln, Interfaces und Routen wieder gelöscht.<br />
<br />
Der untere Abschnitt definiert einen VPN Tunnel in die Fürther Hood. Der Name des Interfaces im Beispiel (ffffuerthVPN) kann individuell neu vergeben werden.<br />
<br><br />
== FastD Start- und Verwaltungsscript ==<br />
Für die Konfiguration von fastd importieren wir eine Datei in ''/etc/fastd'' mit dem Befehl:<br />
<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/fff_beispiel_fastd.sh -P /etc/fastd/<br />
</code><br />
<br />
Alternativ kann das Skript aus einer leeren Datei erstellt werden:<br />
<code><br />
touch /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
danach öffnen wir diese:<br />
<br />
<code><br />
vi /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
und editieren das Skript oder fügen ein Neues ein:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
SERVERNAME="beispiel"<br />
<br />
hood="hoodeintragen"<br />
project="fff"<br />
port=10004<br />
<br />
SERVERNAME="$SERVERNAME.$hood"<br />
<br />
hostname=$SERVERNAME<br />
<br />
if [ ! -d /etc/fastd ]<br />
then<br />
mkdir /etc/fastd<br />
fi<br />
<br />
if [ ! -d /etc/fastd/$project.$hood ]<br />
then<br />
mkdir /etc/fastd/$project.$hood<br />
mkdir /etc/fastd/$project.$hood/peers<br />
<br />
#fastd config<br />
(<br />
echo "# Log warnings and errors to stderr"<br />
echo "log level error;"<br />
echo "# Log everything to a log file"<br />
echo "log to syslog as \"${project}${hood}\" level info;"<br />
echo "# Set the interface name"<br />
echo "interface \"${project}${hood}VPN\";"<br />
echo "# Support xsalsa20 and aes128 encryption methods, prefer xsalsa20"<br />
echo "#method \"xsalsa20-poly1305\";"<br />
echo "#method \"aes128-gcm\";"<br />
echo "method \"null\";"<br />
echo "# Bind to a fixed port, IPv4 only"<br />
echo "bind any:${port};"<br />
echo "# Secret key generated by \"fastd --generate-key\""<br />
echo "secret \"$(fastd --generate-key | grep -i Secret | awk '{print $2}')\";" <br />
echo "# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)" <br />
echo "# (see MTU selection documentation)" <br />
echo "mtu 1426;" <br />
echo "on up \"/etc/fastd/${project}.${hood}/up.sh\";" <br />
echo "on post-down \"/etc/fastd/${project}.${hood}/down.sh\";" <br />
echo "# Include peers from the directory 'peers'" <br />
echo "include peers from \"/etc/fastd/${project}.${hood}/peers\";" <br />
echo "secure handshakes no;"<br />
) >> "/etc/fastd/$project.$hood/$project.$hood.conf"<br />
<br />
#fastd-up<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifdown \$INTERFACE"<br />
) >> /etc/fastd/$project.$hood/down.sh<br />
<br />
chmod +x /etc/fastd/$project.$hood/down.sh<br />
<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifup \$INTERFACE" >> /etc/fastd/$project.$hood/up.sh<br />
) >> /etc/fastd/$project.$hood/up.sh<br />
chmod +x /etc/fastd/$project.$hood/up.sh<br />
fi<br />
<br />
pubkey=$(fastd -c /etc/fastd/$project.$hood/$project.$hood.conf --show-key --machine-readable)<br />
port=$(grep ^bind /etc/fastd/$project.$hood/$project.$hood.conf | cut -d: -f2 | cut -d\; -f1)<br />
<br />
# fire up<br />
if [ "$(/sbin/ifconfig -a | grep -i ethernet | grep ${project}${hood}VPN)" = "" ]<br />
then<br />
/bin/rm /var/run/fastd.$project.$hood.pid<br />
fastd -c /etc/fastd/$project.$hood/$project.$hood.conf -d --pid-file /var/run/fastd.$project.$hood.pid<br />
fi<br />
<br />
# register<br />
wget -T15 -q "http://keyserver.freifunk-franken.de/${project}/?name=$hostname&port=$port&key=$pubkey" -O /tmp/fastd_${project}.${hood}_output <br />
if [ "$?" != "0" ]<br />
then<br />
echo "Update failed"<br />
echo "Exiting, no clean up, no refresh"<br />
exit<br />
fi<br />
<br />
touch /tmp/fastd_${project}.${hood}_starting<br />
<br />
filenames=$(cat /tmp/fastd_${project}.${hood}_output| grep ^#### | sed -e 's/^####//' | sed -e 's/.conf//g')<br />
for file in $filenames<br />
do<br />
grep -A100 ^####$file.conf$ /tmp/fastd_${project}.${hood}_output | grep -v ^####$file.conf$ | grep -m1 ^### -B100 | grep -v ^### | sed 's/ float;/;/g' > "/etc/fastd/$project.$hood/peers/$file"<br />
echo 'float yes;' >> "/etc/fastd/$project.$hood/peers/$file"<br />
done<br />
<br />
#find old peers<br />
OLD=$(find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print)<br />
<br />
if [ -n "${OLD}" ] ; then<br />
echo "Lösche alte:"<br />
echo $OLD<br />
<br />
find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print | xargs /bin/rm /tmp/fastd_${project}.${hood}_starting<br />
fi<br />
<br />
#reload<br />
kill -HUP "$(cat /var/run/fastd.$project.$hood.pid)"<br />
<br />
exit 0<br />
</pre><br />
<br />
Zum Schluss geben wir noch ein<br />
<br />
<code><br />
chmod +x /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
ein, um das Skript ausführbar zu machen.<br />
<br />
Das Skript konfiguriert fastd, indem es<br />
* einen Schlüssel generiert, sollte keiner existieren<br />
* diesen Schlüssel mit dem Keyserver austauscht<br />
* die fastd Konfigurationsdatei anlegt<br />
* den fastd Dämonen startet<br />
<br />
Lediglich der Servername und die Hood müssen oben im Skript händisch angepasst werden. Der Dateiname des Skripts kann individuell angepasst werden.<br />
<br />
Nachdem das Script ausgeführt wurde, sollte man überprüfen ob das Interface in der Konfigurationsdatei unter /etc/fastd/fff.<Hoodname>/fff.<Hoodname>.conf das gleiche ist wie vorher in /etc/network/interfaces festgelegt. Wenn der Name nicht identisch ist (Groß-/Kleinschreibung), werden die Interfaces nicht starten.<br />
<br />
Hinweis: Das Gateway wird standardmässig in die Default-Hood eingebunden. Es wird hier lediglich ein Name für die Konfigurationsdatei und der Gateway Name definiert. Die Zuordnung des Gateways zu der Hood erfolgt später über den KeyXchange (siehe unten).<br />
<br><br />
== IP-Forwarding ==<br />
Um Anfragen, die das Gateway erreichen, weiterzuleiten, muss IP-Forwarding aktiviert werden. <br />
<br />
Manuell geht dies über:<br />
<code><br />
echo "1" > /proc/sys/net/ipv4/ip_forward<br />
<br />
echo "1" > /proc/sys/net/ipv6/conf/default/forwarding<br />
<br />
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding<br />
</code><br />
<br />
Dauerhaft lässt sich IP-Forwarding in /etc/sysctl.conf aktivieren:<br />
<code><br />
vi /etc/sysctl.conf<br />
</code><br />
<br />
.. um dort die Abschnitte einzukommentieren, die das Forwarding steuern:<br />
<pre><br />
.<br />
.<br />
.<br />
# Uncomment the next line to enable packet forwarding for IPv4<br />
net.ipv4.ip_forward=1<br />
<br />
# Uncomment the next line to enable packet forwarding for IPv6<br />
# Enabling this option disables Stateless Address Autoconfiguration<br />
# based on Router Advertisements for this host<br />
net.ipv6.conf.all.forwarding=1<br />
.<br />
.<br />
.<br />
</pre><br />
<br><br />
== Testen von B.A.T.M.A.N, fastd und Autostart ==<br />
Hierfür booten wir das Gateway am besten erst mal neu:<br />
<code><br />
reboot & exit<br />
</code><br />
<br />
und starten das fast.d Startskript manuell: <br />
<code><br />
/etc/fastd/fff_beispiel_fastd.sh &<br />
</code><br />
<br />
Beim Erststart werden Schlüsselpaare generiert und ausgetauscht, es kann also etwas dauern.<br />
<br />
Danach sollte der Aufruf von...<br />
<code><br />
pgrep fastd<br />
</code><br />
... mit der Prozess-ID beantwortet werden: Fastd läuft in dem Fall.<br />
<br />
<br />
Ein Aufruf von ifconfig:<br />
<code><br />
ifconfig<br />
</code><br />
<br />
sollte die neu erstellten Interfaces bat0 und ffffuerthVPN zurückliefern.<br />
Exemplarisch und als Auszug:<br />
<pre><br />
bat0 Link encap:Ethernet HWaddr ea:95:50:07:f7:27 <br />
inet addr:10.50.32.5 Bcast:0.0.0.0 Mask:255.255.248.0<br />
inet6 addr: fe80::e895:50ff:fe07:f727/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:1089992 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:849698 errors:0 dropped:1728 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0 <br />
RX bytes:141311612 (134.7 MiB) TX bytes:1052934594 (1004.1 MiB)<br />
<br />
.<br />
.<br />
.<br />
ffffuerthVPN Link encap:Ethernet HWaddr e6:3b:f3:b7:fc:db <br />
inet6 addr: fe80::e43b:f3ff:feb7:fcdb/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1426 Metric:1<br />
RX packets:32389694 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:2699525 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:500 <br />
RX bytes:4193328694 (3.9 GiB) TX bytes:1384843740 (1.2 GiB)<br />
.<br />
.<br />
.<br />
</pre><br />
Aus dem ifconfig Auszug für bat0 sollte die eingerichtete IP des Gateways und die Netzmaske hervorgehen.<br />
<br />
<br />
Die Abfrage der IP-Regeln:<br />
<code><br />
ip rule<br />
</code><br />
<br />
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):<br />
<pre><br />
32757: from all to 10.0.0.0/8 lookup fff <br />
32758: from 10.0.0.0/8 lookup fff <br />
32759: from all iif bat0 lookup fff <br />
</pre><br />
<br />
Eine Abfrage der fff-Routing Tabelle<br />
<code><br />
ip route show table fff <br />
</code><br />
<br />
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:<br />
<pre><br />
10.50.32.0/21 dev bat0 scope link<br />
</pre><br />
<br />
Ein Aufruf von "batctl o"<br />
<code><br />
batctl o <br />
</code><br />
<br />
ergibt eine Liste der MAC-Adressen von unseren nächsten Nachbarn. Exemplarisch und als Auszug:<br />
<pre><br />
[B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: ffffuerthVPN/e6:3b:f3:b7:fc:db (bat0)]<br />
Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ...<br />
96:43:c4:2e:73:68 0.004s (255) 96:43:c4:2e:73:68 [ffffuerthVPN]: 96:43:c4:2e:73:68 (255)<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
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:<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
Hier spendieren wir einen Eintrag, der fastd mit 10 Sekunden Verzögerung bei jedem Systemstart mitstartet:<br />
<pre><br />
# launch fastd with 10 seconds delay<br />
(sleep 10; sh /etc/fastd/fff_beispiel_fastd.sh) &<br />
</pre><br />
<br />
'''Zusätzlich''' muss ein Cronjob angelegt werden, der das Skript z.B. alle 10 Minuten ausführt:<br />
<code><br />
crontab -e<br />
</code><br />
<br />
Nun folgendes eingeben:<br />
<pre><br />
*/10 * * * * sh /etc/fastd/fff_beispiel_fastd.sh<br />
</pre><br />
<br />
und<br />
<br />
<code><br />
/etc/init.d/cron restart<br />
</code><br />
<br><br />
== OpenVPN-Tunnel einrichten ==<br />
Die Einrichtung eines OpenVPN Tunnels kann von Anbieter zu Anbieter variieren. <br />
Im Laufe der Zeit sollte die Dokumentation so um funktionierende Konfigurationen verschiedener Anbieter erweitert werden.<br />
<br><br />
=== Mullvad ===<br />
Mullvad liefert in der Datei mullvadconfig.zip, die notwendigen Schlüssel (ca.crt, mullvad.crt, mullvad.key) als auch eine Konfigurationsdatei (mullvad_linux.conf) mit, die später angepasst werden muss.<br />
<br />
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:<br />
<br />
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.<br />
<br />
Als unverbindliche Richtschnur für Linux:<br />
<code><br />
scp mullvadconfig.zip root@<ipv4 des Gateways>:/root<br />
</code><br />
<br />
Danach loggen wir uns auf dem Gateway ein und entpacken die Datei (nicht vergessen unzip zu installieren):<br />
<code><br />
ssh root@<ipv4 des Gateways><br />
<br />
unzip mullvadconfig.zip<br />
<br />
cd <Kundennummernverzeichnis><br />
<br />
cp * /etc/openvpn<br />
</code><br />
<br />
''/etc/openvpn/'' sollte mit dem Inhalt des entpackten mullvadconfig.zip Archivs dann so aussehen:<br />
<pre><br />
ca.crt crl.pem mullvad.crt mullvad.key mullvad_linux.conf mullvad-up mullvad_windows.conf.ovpn <br />
</pre><br />
<br />
'''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.<br />
<br />
Wir legen ein benutzerspezifisches start-up Script namens mullvad-up an:<br />
<code><br />
vi /etc/openvpn/mullvad-up<br />
</code><br />
<br />
und füllen sie mit folgendem Inhalt:<br />
<pre><br />
#!/bin/bash<br />
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE<br />
</pre><br />
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.<br />
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.<br />
<br />
Das Skript mullvad-up muss ferner ausführbar sein:<br />
<code><br />
chmod +x /etc/openvpn/mullvad-up<br />
</code><br />
<br />
Dieses spezifische Routing muss zwingend in mullvad_linux.conf eingepflegt werden:<br />
<code><br />
vi /etc/openvpn/mullvad_linux.conf<br />
</code><br />
<br />
und hier die Konfiguration entsprechend geändert werden:<br />
<pre><br />
.<br />
.<br />
.<br />
# Allow calling of built-in executables and user-defined scripts.<br />
script-security 2<br />
<br />
# Parses DHCP options from openvpn to update resolv.conf<br />
#up /etc/openvpn/update-resolv-conf<br />
#down /etc/openvpn/update-resolv-conf<br />
<br />
# Enable Freifunk specific Routing<br />
route-noexec<br />
route-delay 3<br />
route-up /etc/openvpn/mullvad-up<br />
.<br />
.<br />
.<br />
</pre><br />
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.<br />
<br />
Wer möchte, kann in mullvad_linux.conf auch Länder definieren, über die der VPN Traffic laufen soll (Ein- /Auskommentieren).<br />
<br />
Der openvpn Tunnel kann nun testweise gestartet werden:<br />
<code><br />
cd /etc/openvpn<br />
<br />
/usr/sbin/openvpn mullvad_linux.conf &<br />
</code><br />
<br />
und sollte exemplarisch und im Auszug folgendes zurück liefern:<br />
<pre><br />
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<br />
Sun Sep 6 12:45:20 2015 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08<br />
Sun Sep 6 12:45:20 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts<br />
.<br />
.<br />
.<br />
Sun Sep 6 12:45:23 2015 /sbin/ip link set dev tun0 up mtu 1500<br />
Sun Sep 6 12:45:23 2015 /sbin/ip addr add dev tun0 10.114.0.45/16 broadcast 10.114.255.255<br />
Sun Sep 6 12:45:23 2015 /sbin/ip -6 addr add fdef:e287:a479:72::102b/112 dev tun0<br />
Sun Sep 6 12:45:23 2015 /etc/openvpn/mullvad-up tun0 1500 1558 10.114.0.45 255.255.0.0 init<br />
Sun Sep 6 12:45:23 2015 Initialization Sequence Completed<br />
</pre><br />
Wichtig ist hierbei, dass in der vorletztes Zeile unser Freifunk-spezifisches Routing durchgeführt wird.<br />
<br />
Das VPN-Gateway sollte nun als Default Route in der fff-Routingtabelle auftauchen:<br />
<code><br />
ip route show table fff | grep default<br />
</code><br />
<br />
Exemplarisch wäre eine Ausgabe für das Tunnel-Device tun0 und dem VPN-Gateway 10.114.0.1:<br />
<pre><br />
default via 10.114.0.1 dev tun0<br />
</pre><br />
<br />
Auch ein ifconfig Eintrag für das Tunnel Device...<br />
<code><br />
ifconfig<br />
</code><br />
<br />
...sollte jetzt existieren (Exemplarisch und im Auszug):<br />
<pre><br />
.<br />
.<br />
.<br />
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 <br />
inet addr:10.114.0.76 P-t-P:10.114.0.76 Mask:255.255.0.0<br />
inet6 addr: fdad:bdef:735d:72::104a/112 Scope:Global<br />
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1<br />
RX packets:1012476 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:640206 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:100 <br />
RX bytes:1250196616 (1.1 GiB) TX bytes:84979294 (81.0 MiB)<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
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:<br />
<code><br />
vi /etc/rc.local <br />
</code><br />
<br />
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:<br />
<pre><br />
# launch vpn with 5 seconds delay<br />
(sleep 5; /usr/sbin/openvpn /etc/openvpn/mullvad_linux.conf >> /var/log/mullvad_vpn.log &) &<br />
</pre><br />
<br><br />
<br />
=== NordVPN ===<br />
NordVPN liefert die Datei config.zip mit, die für jeden verwendbaren VPN-Server eine seperate Konfigurationsdatei enthält.<br />
<br />
'''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.<br />
<br />
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.<br />
<br />
Als unverbindliche Richtschnur für Linux:<br />
<code><br />
scp config.zip root@<ipv4 des Gateways>:/root<br />
</code><br />
<br />
Und entpacken diese auf dem Gateway:<br />
<code><br />
cd ~<br />
<br />
mkdir nordvpn-configs<br />
<br />
mv config.zip nordvpn-configs<br />
<br />
cd nordvpn-configs<br />
<br />
unzip config.zip<br />
</code><br />
<br />
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.<br />
<br />
Im Beispiel nehmen wir se1.nordvpn.com.udp1194.ovpn und passen Sie zunächst Freifunk-spezifisch an (siehe Aussperr-Hinweis oben):<br />
<br />
<code><br />
vi se1.nordvpn.com.udp1194.ovpn<br />
</code><br />
<br />
Ä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:<br />
<pre><br />
.<br />
.<br />
.<br />
# Provide Username and Password<br />
auth-user-pass /etc/openvpn/nordvpn-pw<br />
.<br />
.<br />
.<br />
# Allow calling of built-in executables and user-defined scripts.<br />
script-security 2<br />
<br />
# Enable Freifunk specific Routing<br />
route-noexec<br />
route-delay 3<br />
route-up /etc/openvpn/nordvpn-up<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
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:<br />
<code><br />
cp se1.nordvpn.com.udp1194.ovpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf<br />
</code><br />
<br />
Hier legen wir noch unser Freifunk Startskript und unsere Password Datei an und machen das Skript ausführbar:<br />
<code><br />
touch /etc/openvpn/nordvpn-up<br />
<br />
touch /etc/openvpn/nordvpn-pw<br />
<br />
chmod +x /etc/openvpn/nordvpn-up<br />
</code><br />
<br />
Man öffnet nordvpn-up...<br />
<code><br />
vi /etc/openvpn/nordvpn-up<br />
</code><br />
<br />
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):<br />
<pre><br />
#!/bin/bash<br />
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE<br />
</pre><br />
<br />
Nun öffnet man nordvpn-pw:<br />
<code><br />
vi /etc/openvpn/nordvpn-pw<br />
</code><br />
<br />
Und legt in der ersten Zeile der Datei seinen NordVPN Usernamen und in der zweiten Zeile sein NordVPN Passwort ab:<br />
<pre><br />
(Username bei NordVPN)<br />
(Password bei NordVPN)<br />
</pre><br />
<br />
Der Tunnel kann nun testweise gestartet werden (hier im Beispiel mit der Konfigurationsdatei se1.nordvpn.com.udp1194.ovpn)<br />
<code><br />
openvpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf &<br />
</code><br />
<br />
Und sollte aufgebaut werden:<br />
<pre><br />
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<br />
.<br />
.<br />
.<br />
Sun Sep 27 09:07:15 2015 /sbin/ip link set dev tun0 up mtu 1500<br />
Sun Sep 27 09:07:15 2015 /sbin/ip addr add dev tun0 local 10.8.8.226 peer 10.8.8.225<br />
Sun Sep 27 09:07:18 2015 Initialization Sequence Completed<br />
</pre><br />
<br />
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:<br />
<code><br />
vi /etc/rc.local <br />
</code><br />
<br />
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:<br />
<pre><br />
# launch vpn with 5 seconds delay<br />
(sleep 5; cd /etc/openvpn ; /usr/sbin/openvpn se1.nordvpn.com.udp1194.ovpn.conf >> /var/log/nordvpn.log &) &<br />
</pre><br />
Die Beispiel-Konfigurationsdatei (se1.nordvpn.com.udp1194.ovpn.conf) muss entsprechend angepasst werden.<br />
<br><br />
== DNS Server ==<br />
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.<br />
<br />
----<br />
<br />
'''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.'''<br />
<br />
----<br />
<br />
Hierfür editieren wir die Datei named.conf.options...<br />
<code><br />
vi /etc/bind/named.conf.options<br />
</code><br />
<br />
...und tragen die DNS Server, die wir anfragen wollen, wenn wir die Information nicht selber haben, als forwarders ein:<br />
<pre><br />
.<br />
.<br />
.<br />
forwarders {<br />
10.50.32.1;<br />
10.50.32.2;<br />
8.8.8.8;<br />
};<br />
allow-query { <br />
127.0.0.1/8; <br />
10.0.0.0/8; <br />
};<br />
.<br />
.<br />
. <br />
</pre><br />
In diesem Fall werden die Freifunk Gateways ro1 (10.50.32.1) und fff-nue1 (10.50.32.2) der Fürther Hood als auch Google DNS (8.8.8.8) als Forwarders definiert. Für andere Hoods muss die lokale Adresse der Freifunk DNS Server unter [[Portal:Netz]] ermittelt werden (z.B. 10.50.48.1 für ro1 in der Ansbacher Hood).<br />
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".<br />
<br />
Neustart des DNS-Servers mit der neuen Konfiguration:<br />
<code><br />
/etc/init.d/bind9 restart<br />
</code><br />
<br />
Testen können wir, indem wir vom DNS Server des Gateways (localhost/127.0.0.1) eine DNS-Auflösung abfragen. <br />
<br />
Ein DNS Resolve für freifunk-franken.de ...<br />
<code><br />
dig @127.0.0.1 freifunk-franken.de<br />
</code><br />
<br />
...sollte von uns selber (Server localhost; 127.0.0.1) beantwortet werden:<br />
<pre><br />
;; global options: +cmd<br />
<br />
;; Got answer:<br />
<br />
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5819<br />
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1 <br />
;; OPT PSEUDOSECTION:<br />
; EDNS: version: 0, flags:; udp: 4096<br />
<br />
;; QUESTION SECTION:<br />
;freifunk-franken.de. IN A<br />
;; ANSWER SECTION:<br />
freifunk-franken.de. 3599 IN A 31.172.113.113 <br />
.<br />
. <br />
.<br />
;; Query time: 117 msec<br />
;; SERVER: 127.0.0.1#53(127.0.0.1)<br />
;; WHEN: Tue Sep 08 14:16:32 EEST 2015<br />
;; MSG SIZE rcvd: 275<br />
</pre><br />
<br><br />
<br />
== B.A.T.M.A.N Gateway Selection ==<br />
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.<br />
<br />
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:<br />
* Bandbreite der Netzanbindung (z.B. 100 Mbit/sec, gesplittet in 50 Mbit/sec up/down)<br />
* 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)<br />
* Erfahrungswerten / eigenes Ermessen<br />
* Bandbreite, bei dem der Gateway Prozessor ausgelastet ist<br />
<br />
Eventuell muss zuerst bc nachinstalliert werden, falls nicht vorhanden:<br />
<code><br />
apt-get install bc<br />
</code><br />
<br />
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.<br />
<br />
Importieren des Skripts aus einer Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/dyn_announce_gw_bw.sh -P /usr/local/bin/<br />
</code><br />
<br />
Alternativ kann das Skript auch als leere Datei erstellt werden:<br />
<code><br />
touch /usr/local/bin/dyn_announce_gw_bw.sh<br />
</code><br />
<br />
Wir machen das Skript ausführbar und öffnen die Datei:<br />
<code><br />
chmod +x /usr/local/bin/dyn_announce_gw_bw.sh<br />
<br />
vi /usr/local/bin/dyn_announce_gw_bw.sh<br />
</code><br />
<br />
Und Füllen dieses mit Inhalt oder editieren den importierten Inhalt:<br />
<pre><br />
#!/bin/bash<br />
gwsel_lockfile="/tmp/gwsel_lockfile" # lockfile to allow for low bandwidth settings <br />
<br />
if [ -z "$1" ]; then<br />
echo<br />
echo "usage: $0 <network-interface> <update_interval [sec]> <total BW up [Mbit/sec]> <total BW down [Mbit/sec]>"<br />
echo<br />
echo "e.g. $0 eth0 60 10 10"<br />
echo<br />
exit<br />
fi<br />
<br />
while true<br />
do<br />
if [ ! -e ${gwsel_lockfile} ]; then # lockfile not present<br />
# Bandwidth currently used (time averaged)<br />
R1=$(cat "/sys/class/net/$1/statistics/rx_bytes")<br />
T1=$(cat "/sys/class/net/$1/statistics/tx_bytes")<br />
sleep "$2"<br />
R2=$(cat "/sys/class/net/$1/statistics/rx_bytes")<br />
T2=$(cat "/sys/class/net/$1/statistics/tx_bytes")<br />
TkbitPS=$(echo "scale=0; ($T2 - $T1) / 1024 * 8 / $2" | bc -l)<br />
RkbitPS=$(echo "scale=0; ($R2 - $R1) / 1024 * 8 / $2" | bc -l)<br />
# echo "BW used -- up $1: $TkbitPS kBit/s; down $1: $RkbitPS kBit/s"<br />
<br />
# Remaining bandwidth available; cut-off negative values<br />
Tavail_kbitPS=$(echo "scale=0; if (($3 * 1024 - $TkbitPS) >0) ($3 * 1024 - $TkbitPS) else 0" | bc -l)<br />
Ravail_kbitPS=$(echo "scale=0; if (($4 * 1024 - $RkbitPS) >0) ($4 * 1024 - $RkbitPS) else 0" | bc -l)<br />
# echo "BW available -- up $1: $Tavail_kbitPS kBit/s; down $1: $Ravail_kbitPS kBit/s"<br />
else # lockfile present<br />
Tavail_kbitPS=0<br />
Ravail_kbitPS=0<br />
sleep "$2"<br />
fi<br />
<br />
for bat in /sys/class/net/bat*; do<br />
iface=${bat##*/}<br />
batctl -m $iface gw_mode server "${Ravail_kbitPS}kbit/${Tavail_kbitPS}kbit" <br />
done<br />
done<br />
</pre><br />
<br />
Das Skript übernimmt als Parameter:<br />
* Netzwerkinterface, das es zu überwachen gilt (i.d.R. eth0)<br />
* 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)<br />
* Upload Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)<br />
* Download Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)<br />
<br />
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 olsr Defaultroute mit geringer Bandbreite verfügbar ist.<br />
<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.:<br />
<code><br />
/usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10<br />
</code><br />
<br />
Um die Gateway Selection beim Systemsstart zu aktivieren, können wir das Skript z.B. in rc.local aufrufen:<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
um dort, leicht zeitverzögert, o.a. Befehl einzupflegen, wobei die Parametrisierung noch Gateway-spezifisch angepasst werden muss:<br />
<pre><br />
.<br />
.<br />
.<br />
#enable batman GW selection with 15 seconds delay<br />
(sleep 15; /usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10) &<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
ACHTUNG! Bei mehreren bat Interfaces (weil man in mehreren Hoods Gateway ist) muss diese Einstellung für jedes Gateway gesetzt werden, hier muss das Script unbedingt überarbeitet werden!<br />
<br />
<pre><br />
batctl -m $batX gw_mode xxmbit/xxmbit<br />
</pre><br />
<br />
und dies für jedes batX Interface. Das Script muss daraufhin noch angepasst werden.<br />
<br />
<br />
auf den Routern kann der vorselektierte Gateway mit <br />
<br />
<code><br />
batctl gwl<br />
</code><br />
<br />
angeguckt werden. Ich vermute das der Gateway mit den Pfeil vorne der vorselektierte Gateway ist, allerdings machen erste beobachtete Daten bisher in meinen Augen noch keinen wirklichen Sinn.<br />
<br><br />
<br />
== DHCP Server ==<br />
Die DHCP Konfiguration kann schon mal vorbereitet werden, sollte aber erst mit als letzter Schritt scharf geschaltet werden. Ein DHCP-Server, der Clients nicht funktionierende DNS-Server oder ein nicht funktionierendes Gateway mitteilt, sperrt diese aus dem Freifunk Netz aus.<br />
<br />
In isc-dhcp-server definieren wir ...<br />
<code><br />
vi /etc/default/isc-dhcp-server<br />
</code><br />
<br />
... das der DHCP Server für das B.A.T.M.A.N Device Anfragen beantworten soll:<br />
<pre><br />
.<br />
.<br />
<br />
INTERFACES="bat0"<br />
.<br />
.<br />
</pre><br />
<br />
Nachfolge Konfiguration wird in auskommentierter Form vorbereitet und sollte erst im letzten Schritt durch Einkommentieren und durch einen Neustart des DHCP Servers...<br />
<code><br />
/etc/init.d/isc-dhcp-server restart<br />
</code><br />
...aktiviert werden.<br />
<br />
Die Konfiguration wird in dhcpd.conf vorgenommen:<br />
<code><br />
vi /etc/dhcp/dhcpd.conf<br />
</code><br />
<br />
und folgender Konfigurationsblock zunächst auskommentiert eingefügt, wobei Gateway und Hood spezifische Änderungen noch eingepflegt werden müssen:<br />
<pre><br />
.<br />
.<br />
.<br />
### Freifunk Franken<br />
#option domain-name "fff.community";<br />
#option domain-name-servers 10.50.16.1;<br />
#authoritative;<br />
### Fuerth<br />
#subnet 10.50.32.0 netmask 255.255.248.0 { # Netzwerk und Netzmaske der Fuerther Hood<br />
# range 10.50.38.0 10.50.39.254; # IP-Range die der DHCP-Server innerhalb der Fuerther Hood verwaltet <br />
# option routers 10.50.32.5; # Default-Gateway, dass Clients mitgeteilt wird <br />
# option domain-name-servers 10.50.32.5, 10.50.32.1; # Name-Server, die Clients mitgeteilt werden<br />
#}<br />
</pre><br />
<br />
Netzwerk und Netzmaske müssen derjenigen der Hood des Gateways entsprechen. Im Beispiel ist dies Fürth, für z.B. Hassberge hieße der Eintrag "subnet 10.50.56.0 netmask 255.255.252.0".<br />
<br />
Der IP-Bereich (Range), die der DHCP-Server in der Hood verwaltet, wurde zuvor unter [[Portal:Netz]] reserviert.<br />
<br />
Unter Routers wird den Clients das Default-Gateway mitgeteilt: Das Gateway, über das Clients das Internet oder eine andere Hood erreichen. In unserem Beispiel routet das aufgesetzte Gateway selber via VPN ins Internet oder via olsr (später) in andere Hoods. Als Default-Gateway wird also die eigene statische IP des Gateways, aus der eigenen Hood, die in [[Portal:Netz]] reserviert wurde, verwendet.<br />
<br />
Ähnlich verhält es sich mit den Nameservern: Auf unserem Gateway wurde ein DNS Server eingerichtet, also kann der domain-name-server unser eigenes Gateway, mit der reservierten statische IP aus der Hood, wie in [[Portal:Netz]], sein. Als Backup empfiehlt sich ein weiterer DNS-Server aus der Hood, in unserem Beispiel ro1 in der Fürther.<br />
<br><br />
<br />
== GRE-Tunnel zu anderen Gateways ==<br />
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]].<br />
<br />
Der GRE-Tunnel wird in /etc/network/interfaces...<br />
<code><br />
vi /etc/network/interfaces<br />
</code><br />
<br />
...mit folgenden noch auf das Gateway anzupassenden Einträgen deklariert:<br />
<pre><br />
auto <tunnel><br />
iface <tunnel> inet static<br />
address <Eigene IPv4 (Freifunk Netz)><br />
pre-up ip -4 tunnel add $IFACE mode gre local <Eigene IPv4 (Internet)> remote <IPv4 des Tunnelpartners (Internet)> ttl 255<br />
#pre-up ip -6 tunnel add $IFACE mode ip6gre local <Eigene IPv6 (Internet)> remote <IPv6 des Tunnelpartners (Internet)> ttl 255<br />
<br />
up ifconfig $IFACE multicast<br />
pointopoint <IPv4 des Tunnelpartners (Freifunk Netz)><br />
post-up iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu<br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.50.0.0/16 table fff<br />
post-up ip rule add to 10.50.0.0/16 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ip rule del from 10.50.0.0/16 table fff<br />
post-down ip rule del to 10.50.0.0/16 table fff<br />
post-down iptables -t mangle -D POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu<br />
post-down iptunnel del $IFACE<br />
</pre><br />
<br />
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.<br />
<br />
'''Beispiel:''' <br />
Um als fff-nue1 einen Tunnel zu ro1 aufzubauen, können die IP-Adressen wie folgt gewählt werden:<br />
<pre><br />
<tunnel> ro1<br />
<Eigene IPv4 (Freifunk Netz)> fff-nue1 10.50.252.1<br />
<IPv4 des Tunnelpartners (Freifunk Netz)> ro1 10.50.252.0<br />
<Eigene IPv4 (Internet)> fff-nue1 31.172.33.99<br />
<IPv4 des Tunnelpartners (Internet)> ro1 176.126.221.7<br />
</pre><br />
<br />
In der Partnerkonfiguration für ro1 werden die Rollen entsprechend vertauscht:<br />
<pre><br />
<tunnel> fff-nue1<br />
<Eigene IPv4 (Freifunk Netz)> ro1 10.50.252.0<br />
<IPv4 des Tunnelpartners (Freifunk Netz)> fff-nue1 10.50.252.1<br />
<Eigene IPv4 (Internet)> ro1 176.126.221.7<br />
<IPv4 des Tunnelpartners (Internet)> fff-nue1 31.172.33.99 <br />
</pre><br />
<br />
Der Tunnel kann über den Aufruf von<br />
<code><br />
ifup <tunnel><br />
</code><br />
...aufgebaut werden, wobei <tunnel> der Name des GRE-Interfaces ist (im Beispiel ro1)<br />
<br />
Nach Aufruf von ifconfig..<br />
<code><br />
ifconfig <br />
</code><br />
sollten wir einen Eintrag für den Tunnel (in diesem Beispiel ro1) vorfinden:<br />
<pre><br />
.<br />
.<br />
.<br />
ro1 Link encap:UNSPEC HWaddr B0-7B-1C-73-30-30-3A-35-00-00-00-00-00-00-00-00 <br />
inet addr:10.50.252.1 P-t-P:10.50.252.0 Mask:255.255.255.255<br />
inet6 addr: fe80::200:5efe:b07b:1c73/64 Scope:Link<br />
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1476 Metric:1<br />
RX packets:160913 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:146654 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0 <br />
RX bytes:66984353 (63.8 MiB) TX bytes:10675001 (10.1 MiB)<br />
.<br />
.<br />
.<br />
</pre><br />
<br><br />
== OLSR ==<br />
=== Basiskonfiguration ===<br />
Mittels OLSR können die Gateways selbstständig Routinginformationen austauschen. Ähnlich wie B.A.T.M.A.N einzelne Router innerhalb einer Hood vermesht (Level 2 Netz), handelt es sich bei olsr um ein mesh zwischen den Gateways (Level 3). Es ermöglicht ein Freifunk Franken internes Routing: z.B. kann eine beliebige IPv4 aus der Nürnberger Hood aus der Fürth Hood heraus erreicht werden.<br />
<br />
Vorlagen können unter Sicherung der Originaldateien wie folgt importiert werden:<br />
<code><br />
mv /etc/default/olsrd /etc/default/olsrd.orig<br />
<br />
mv /etc/olsrd/olsrd.conf /etc/olsrd/olsrd.conf.orig<br />
<br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd -P /etc/default/<br />
<br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd.conf -P /etc/olsrd/<br />
</code><br />
<br />
Zunächst zeigen wir die Interfaces an, unter dem wir olsr Routing Informationen austauschen:<br />
<code><br />
vi /etc/default/olsrd<br />
</code><br />
<br />
Im Beispiel wird über die 2 GRE-Tunnel nue1 und ro1 ausgetauscht, dies muss entsprechend der GRE-Tunnel Konfiguration angepasst werden: <br />
<pre><br />
.<br />
.<br />
#<br />
# Uncomment the next line run olsrd automatically at startup<br />
#<br />
START_OLSRD="YES"<br />
<br />
#<br />
# Uncomment the next line to force-configure the wifi interface to be setup<br />
# for ad-hoc mode using the /usr/sbin/olsrd-adhoc-setup script whenever olsrd<br />
# is started.<br />
#<br />
SETUP_ADHOC="NO"<br />
.<br />
.<br />
.<br />
#<br />
# Specify the network interfaces that olsrd will run on, this will most likely<br />
# be your wifi interface.<br />
#<br />
MESH_IF="nue1 ro1" <br />
.<br />
.<br />
</pre><br />
<br />
<br />
Weiter wird dann hier ...<br />
<code><br />
vi /etc/olsrd/olsrd.conf<br />
</code><br />
... konfiguriert. <br />
Da unser Beispiel-Gateway ins Netz der Fürther Hood eingebunden ist, teilen wir dies andern Gateways über den Eintrag 10.50.32.0/21 mit:<br />
<pre><br />
.<br />
.<br />
.<br />
# HNA IPv4 routes<br />
# syntax: netaddr netmask<br />
# Example Internet gateway:<br />
# 0.0.0.0 0.0.0.0<br />
<br />
Hna4<br />
{<br />
# Internet gateway:<br />
# 0.0.0.0 0.0.0.0<br />
# more entries can be added:<br />
# 192.168.1.0 255.255.255.0<br />
10.50.32.0/21<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Hier wird das olsr Webinterface auf port 8080 konfiguriert:<br />
<br />
<pre><br />
.<br />
.<br />
.<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
# defaults to 1978<br />
PlParam "Port" "8080"<br />
# if you dont set these, the default is to listen only on the loopback device<br />
#PlParam "Host" "80.23.53.22"<br />
#PlParam "Net" "10.0.0.0 255.0.0.0"<br />
PlParam "Net" "0.0.0.0 0.0.0.0"<br />
#PlParam "Host" "127.0.0.1"<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Ferner wird der VPN-Tunnel (hier tun0) per persönlich angepasstem ping Kommando auf sein Funktion hin überwacht. Sollte der VPN-Tunnel ausfallen, ermöglicht olsr im Zusammenspiel mit der Routing Priorisierung (s.u) und der OpenVPN Start-/Stop Automatik (s.u.) ein automatisches Re-Routing:<br />
<pre><br />
.<br />
.<br />
.<br />
LoadPlugin "olsrd_dyn_gw.so.0.5"<br />
{<br />
# Here parameters are set to be sent to the<br />
# plugin. Theese are on the form "key" "value".<br />
# Parameters ofcause, differs from plugin to plugin.<br />
# Consult the documentation of your plugin for details.<br />
<br />
# Example: dyn_gw params<br />
<br />
# how often to check for Internet connectivity<br />
# defaults to 5 secs<br />
PlParam "Interval" "5"<br />
<br />
# if one or more IPv4 addresses are given, do a ping on these in<br />
# descending order to validate that there is not only an entry in<br />
# routing table, but also a real internet connection. If any of<br />
# these addresses could be pinged successfully, the test was<br />
# succesful, i.e. if the ping on the 1st address was successful,the<br />
# 2nd won't be pinged<br />
PlParam "Ping" "8.8.8.8"<br />
PlParam "Ping" "82.165.230.17"<br />
PlParam "pingcmd" "ping -c 1 -q -I tun0 %s"<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Folgender Konfigurationsblock muss ans Ende der Konfigurationsdatei angefügt werden. Es ermöglich olsr die Manipulation der fff-Routingtabelle:<br />
<pre><br />
.<br />
.<br />
.<br />
# Specify the proto tag to be used for routes olsr inserts into kernel<br />
# currently only implemented for linux<br />
# valid values under linux are 1 .. 254<br />
# 1 gets remapped by olsrd to 0 UNSPECIFIED (1 is reserved for ICMP redirects)<br />
# 2 KERNEL routes (not very wise to use)<br />
# 3 BOOT (should in fact not be used by routing daemons)<br />
# 4 STATIC<br />
# 8 .. 15 various routing daemons (gated, zebra, bird, & co)<br />
# (defaults to 0 which gets replaced by an OS-specific default value<br />
# under linux 3 (BOOT) (for backward compatibility)<br />
#<br />
RtProto 8<br />
#<br />
# Specifies the routing Table olsr uses<br />
# RtTable is for host routes, RtTableDefault for the route to the default<br />
# internet gateway (2 in case of IPv6+NIIT) and RtTableTunnel is for<br />
# routes to the ipip tunnels, valid values are 1 to 254<br />
# There is a special parameter "auto" (choose default below)<br />
# (with smartgw: default is 254/223/224)<br />
# (without smartgw: default is 254/254/254, linux main table)<br />
#<br />
RtTable 10<br />
RtTableDefault 10<br />
RtTableTunnel 10<br />
#<br />
# Specifies the policy rule priorities for the three routing tables and<br />
# a special rule for smartgateway routing (see README-Olsr-Extensions)<br />
# Priorities can only be set if three different routing tables are set.<br />
# if set the values must obey to condition<br />
# RtTablePriority < RtTableDefaultOlsrPriority<br />
# < RtTableTunnelPriority < RtTableDefaultPriority.<br />
# There are two special parameters, "auto" (choose fitting to SmartGW<br />
# mode) and "none" (do not set policy rule)<br />
# (with smartgw: default is none/32776/32776/32796)<br />
# (without smartgw: default is none/none/none/none)<br />
#<br />
# RtTablePriority auto<br />
# RtTableDefaultOlsrPriority auto<br />
# RtTableTunnelPriority auto<br />
# RtTableDefaultPriority auto<br />
</pre><br />
<br />
<br />
Das Freifunk Franken intere Routing kann nun getestet werden.<br />
<br />
Zunächst einmal starten wir olsr neu:<br />
<code><br />
/etc/init.d/olsrd restart<br />
</code><br />
<br />
<br />
Die Routinginformationen des olsr-meshes sollten in der fff-Routingtabelle auftauchen:<br />
<code><br />
ip route show table fff<br />
</code><br />
<br />
Exemplarischer Auszug:<br />
<pre><br />
.<br />
.<br />
.<br />
10.50.32.1 via 10.50.32.1 dev ro1 proto gated metric 2 onlink <br />
10.50.32.2 via 10.50.32.2 dev nue1 proto gated metric 2 onlink <br />
10.50.40.0/21 via 10.50.32.1 dev ro1 proto gated metric 2 onlink <br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Eine IP4 aus der Nürnberger Hood (10.50.40.0/21) sollte z.B. von Fürth aus (10.50.32.0/21) erreichbar sein:<br />
<br />
<code><br />
ping 10.50.40.3<br />
</code><br />
<br />
Antwort:<br />
<pre><br />
PING 10.50.40.3 (10.50.40.3) 56(84) bytes of data.<br />
64 bytes from 10.50.40.3: icmp_seq=1 ttl=63 time=42.2 ms<br />
64 bytes from 10.50.40.3: icmp_seq=2 ttl=63 time=42.7 ms<br />
^C<br />
--- 10.50.40.3 ping statistics ---<br />
2 packets transmitted, 2 received, 0% packet loss, time 1000ms<br />
rtt min/avg/max/mdev = 42.279/42.516/42.753/0.237 ms<br />
</pre><br />
<br><br />
=== OpenVPN Start/Stop Automatik ===<br />
OLSR testet mit dem Dynamic Gateway Plugin, ob die Default Route über den OpenVPN Tunnel noch funktioniert, indem regelmässig teilweise mehrere verschiedene Ziele über den Tunnel angepingt werden. Sollte der OpenVPN Tunnel nicht mehr funktionieren, baut OLSR eine neue Default-Route zu einem anderem Gateway auf, über das dann der Internet-Traffic läuft. Beide Default-Routen, die über den OpenVPN Tunnel und die von OLSR, existieren parallel, wobei zunächst weiterhin die OpenVPN Verbindung verwendet wird.<br />
<br />
Da die OpenVPN Verbindung ausgefallen ist, aber trotzdem noch als bevorzugte Default-Route eingetragen ist, ist die Internetanbindung bis die Störung VPN-Server seitig behoben ist, trotzdem nicht verfügbar. <br />
<br />
Für diesen Anwendungsfall wird ein Skript vorgeschlagen, dass die Funktion des OpenVPN Tunnels überwacht und den Tunnel (und die OpenVPN Default-Route) bei Nicht-Funktion abbaut. Um die Funktion zu überprüfen werden in regelmässigen Abständen 2 verschiedene Ziele über den Tunnel angepingt. Scheitert dies, wird der Tunnel für einen gewissen Zeitraum abgebaut, in dem dann stattdessen das OLSR Dynamic Gateway Plugin das Routing übernimmt. Danach wird die Verbindung wieder aufgebaut. Anschliessend wird überprüft, ob der OpenVPN-Tunnel wieder funktioniert. Tut er es nicht, wird er wieder abbgebaut, funktioniert er, bleibt er bis zur Detektion der nächsten Störung als Internetanbindung erhalten.<br />
<br />
Man importiert die Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/auto_start-stop_ovpn.sh -P /usr/local/bin/<br />
</code><br />
<br />
Alternativ kann man statt der Vorlage auch eine leere Datei anlegen:<br />
<code><br />
touch /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
Man macht das Skript ausführbar:<br />
<code><br />
chmod +x /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
<br />
Nun öffnet man die Datei im Editor ...<br />
<code><br />
vi /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
... und füllt sie mit Inhalt oder editiert den importierten Inhalt:<br />
<pre><br />
#!/bin/bash<br />
<br />
IF="tun0" # Interface used for ping<br />
ping1_target="8.8.8.8" # IP no. 1 used for ping<br />
ping2_target="82.165.229.31" # IP no. 2 used for ping<br />
ping_interval="5" # waiting time in-between two pings<br />
switchback_interval="3600" # waiting time for interface to recover before probing again<br />
start_grace="10" # waiting time to allow for tunnel restart<br />
logfile="/dev/null" # logfile for debug<br />
gwsel_lockfile="/tmp/gwsel_lockfile" # lockfile to allow for low bandwidth settings <br />
<br />
openvpn_stop-cmd () { # command used disabling tunnel<br />
service openvpn stop # ubuntu<br />
#/etc/init.d/openvpn stop # debian<br />
#killall openvpn # hardcore<br />
}<br />
<br />
openvpn_start-cmd () { # command used enabling tunnel<br />
service openvpn start # ubuntu<br />
#/etc/init.d/openvpn start # debian<br />
#openvpn /etc/openvpn/*.conf & # hardcore<br />
}<br />
<br />
ping1 () {<br />
echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF" &>> $logfile<br />
ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF &>> $logfile<br />
ping1_ExitCode=$?<br />
echo "$(date): Exit Status: ${ping1_ExitCode}" &>> $logfile<br />
}<br />
<br />
ping2 () {<br />
echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF" &>> $logfile<br />
ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF &>> $logfile<br />
ping2_ExitCode=$?<br />
echo "$(date): Exit Status: ${ping2_ExitCode}" &>> $logfile<br />
}<br />
<br />
<br />
while true<br />
do<br />
# wait for interface build-up, if interface not present<br />
if [ ! -h "/sys/class/net/$IF" ]; then<br />
echo "$(date): Interface $IF not detected. Waiting ${start_grace} seconds." &>> $logfile<br />
sleep ${start_grace}<br />
fi<br />
<br />
# perform ping<br />
ping1<br />
ping2<br />
<br />
# check if ping successful<br />
if ([[ ${ping1_ExitCode} -eq 0 ]] || [[ ${ping2_ExitCode} -eq 0 ]]); then<br />
sleep ${ping_interval}<br />
else<br />
logger -t "$0" ${ping1_target} and ${ping2_target} not reached via interface $IF.<br />
echo "$(date): ${ping1_target} and ${ping2_target} not reached via interface $IF." &>> $logfile<br />
touch ${gwsel_lockfile} &>> $logfile<br />
<br />
if [ -h "/sys/class/net/$IF" ]; then<br />
logger -t "$0" Stopping interface $IF.<br />
echo "$(date): Stopping interface $IF." &>> $logfile<br />
openvpn_stop-cmd &>> $logfile<br />
fi<br />
<br />
sleep ${switchback_interval}<br />
rm -f ${gwsel_lockfile} &>> $logfile<br />
<br />
if [ ! -h "/sys/class/net/$IF" ]; then<br />
logger -t "$0" Restoring interface $IF to probe for recovery.<br />
echo "$(date): Restoring interface $IF to probe for recovery." &>> $logfile<br />
openvpn_start-cmd &>> $logfile<br />
fi<br />
fi<br />
done<br />
</pre><br />
<br />
Hierbei können im Skript folgende Anpassungen vorgenommen werden:<br />
*openvpn_stop-cmd: Der Befehl, mit dem der OpenVPN Tunnel '''abgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ als Prozess gekillt werden.<br />
*openvpn_start-cmd: Der Befehl, mit dem der OpenVPN tunnel '''aufgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ per openvpn Kommandozeilenaufruf gestartet werden.<br />
*IF: Das OpenVPN Tunnel Device. Normalerweise ist das tun0.<br />
*ping1_target,ping2_target: Die IP-Adressen die über das Tunnel-Interface IF angepingt werden, um den Tunnel auf Funktion zu überprüfen. Vorauswahl: Google DNS und Web.de<br />
*ping_interval: Der zeitliche Anstand zwischen zwei Ping-Versuchen. Vorauswahl: 5 Sekunden.<br />
*switchback_interval: Der Zeitraum, den der Tunnel abgebaut bleibt, sollte er als nicht-funktionierend erkannt worden sein. Es wird ein träges Verhalten empfohlen. Vorauswahl: 3600 Sekunden.<br />
*start_grace: Der Zeitraum, der dem Tunnel zum Starten eingeräumt wird. Die Timer-Funktion macht ferner das Skript gegen Restarts des Tunnels unempfindlich.<br />
*logfile: Für Debug Zwecke kann man detaillierte Ausgaben hier in eine Datei umleiten.<br />
*gwsel_lockfile: Setzt bei Störumschaltung ein Lockfile, dass von dem Skript der Gateway Selection (s.o.) ausgewertet werden kann, um eine kleinere Bandbreite für die Dauer der Störumschaltung zu annoncieren. Das Lockfile wird beim Wiederstart des OpenVPN Tunnels gelöscht.<br />
<br />
Das Skript selber kann manuell ...<br />
<code><br />
auto_start-stop_ovpn.sh &<br />
</code><br />
<br />
...und bei jedem Systemstart mit gestartet werden, indem es z.B. in /etc/rc.local ...<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
...wie folgt eingetragen wird:<br />
<pre><br />
.<br />
.<br />
.<br />
#enable tunnel monitoring with 60 seconds delay<br />
(sleep 60; auto_start-stop_ovpn.sh &) &<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Getestet werden kann das Skript z.B., indem man sich alle Default-Routen der fff-Tabelle anzeigen lässt: <br />
<code><br />
watch "ip route show table fff | grep default"<br />
</code><br />
<br />
und parallel dazu auf einer zweiten Shell das openvpn deaktiviert:<br />
<code><br />
killall openvpn<br />
</code><br />
<br />
Es sollte eine neue Default-Route zu einem anderen Gateway aufgebaut werden, über die der Internet-Traffic dann läuft. Die Route über den OpenVPN Tunnel sollte verschwinden. Nach der eingestellten Zeit wird der OpenVPN Tunnel durch das Skript wieder reaktiviert. Danach existieren beide Default-Routen parallel, bis OLSR seine Route automatisch wieder abbaut. Die OpenVPN Default-Route bleibt und ist wieder aktiv.<br />
<br><br />
<br />
=== Priorisieren von OLSR Routen ===<br />
OLSR erstellt die fff-Routingtabelle selbstständig, indem es die Linkqualität anhand von Algorithmen bewertet. Diese Bewertung ist recht volatil, was dazu führen kann, das die von OLSR ausgesuchte Default-Route häufig wechselt. Für die verbundenen Clients wechselt jedes mal die externe Internet IP mit, je nachdem über welches Gateway OLSR den Internet-Traffic gerade abwirft. Bei IP-Wechsel stoppen z.B. Downloads aus dem Internet, stoppen Videos im Abspielen, werden ssh Verbindungen gekappt.<br />
<br />
Um diese Dynamik nicht allzu schnell zu gestalten, empfiehlt es sich OLSR eine oder zwei Default-Routen mitzuteilen, die bevorzugt verwendet werden. Zusätzlich wird NatThreshold, einen Schwellwert den die neue Default-Route besser sein muss als die alte, bevor gewechselt wird, definiert.<br />
<br />
Dies geschieht über Gewichtungsfaktoren in olsrd.conf:<br />
<br />
<code><br />
vi /etc/olsrd/olsrd.conf<br />
</code><br />
<br />
Routen kann man im Abschnitt InterfaceDefaults priorisieren. <br />
Hier können Gewichtungsfaktoren für die GRE-Tunnel zu anderen Gateways eingeführt werden, mit denen die Link-Qualität beeinflusst werden kann:<br />
<pre><br />
.<br />
.<br />
.<br />
# If a certain route should be preferred<br />
# or ignored by the mesh, the Link Quality<br />
# value of a node can be multiplied with a factor<br />
# entered here. In the example the route<br />
# using 192.168.0.1 would rather be ignored.<br />
# A multiplier of 0.5 will result in a small<br />
# (bad) LinkQuality value and a high (bad)<br />
# ETX value.<br />
<br />
# preferred link<br />
LinkQualityMult <tunnel1_ip> 0.99<br />
<br />
# preferred link<br />
LinkQualityMult <tunnel2_ip> 0.99<br />
<br />
# This multiplier applies to all other nodes<br />
LinkQualityMult default 0.7<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Im Beispiel werden alle Routen herabgestuft (Faktor 0.7), mit der Ausnahme derer die über <tunnel1_ip> oder <tunnel2_ip> laufen (Faktor 0.99). <tunnel_ip1> sind dabei die Point-to-Point Partner IPs der GRE Tunnel der jeweiligen Gateways im Freifunk Netz. Die nicht herabgestuften Routen können analog als priorisiert betrachtet werden. Für eine Priorisierung der Route von nue1 zu ro1 wäre die <tunnel1/2_ip> z.B. die 10.50.252.1 (Vgl. [[Portal:Netz]]).<br />
<br />
NatThreshold wird im Hauptabschnitt von olsrd.conf definiert:<br />
<pre><br />
.<br />
.<br />
# If the NAT-Endpoint (the preferred 0/0 HNA emitting node)<br />
# is to be changed, the ETX value of the current 0/0 is<br />
# multiplied with the NatThreshold value before being<br />
# compared to the new one<br />
# The parameter can be a value between 0.1 and 1.0, but<br />
# should be close to 1.0 if changed.<br />
<br />
NatThreshold 0.7<br />
.<br />
.<br />
</pre><br />
<br />
Im Beispiel muss die Linkqualität der neuen Default-Route um 30% besser bewertet als die aktuelle sein, bevor die Default-Route gewechselt wird.<br />
<br />
Die Änderungen werden nach Neustart von OLSR aktiv:<br />
<code><br />
/etc/init.d/olsrd restart<br />
</code><br />
<br><br />
= Einbringen des Gateways in die Hood / Keyserver =<br />
Abschliessend muss das Gateway im Keyserver als Gateway der entsprechenden Hood eingetragen werden. Hierfür benötigt man einen Keyserver-Administrator => [[Server]].<br />
<br />
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.<br />
<br />
Der DHCP-Server sollte als letzter Schritt aktiviert werden (s.o.)<br />
<br><br />
= Transparent Proxy =<br />
Auf dem Gateway kann (aber muss nicht) ein Proxy-Server installiert werden, der Dateien (z.B. Bilder), die schon mal angefragt wurden, nicht aus dem Internet holt, sondern als "lokal" gespeicherte Datei direkt vom Gateway bereitstellt. Die Clients werden dabei über den Proxy gezwungen, d.h. das Gateway leitet die Anfragen pauschal an den Proxy weiter, welcher entscheidet ob der die Anfrage selber bedient oder Gateway-extern anfragt. <br />
<br />
Die Einrichtung eines Proxys ist '''optional''', d.h. der Proxy ist für die Funktion des Gateways nicht notwendig. Proxy-Server reduzieren Antwortzeiten und Traffic für sich '''häufig''' wiederholende Anfragen (z.B. Spiegel Online, Windows Update).<br />
<br />
'''Hinweis''': <br />
Die Einrichtung eines Proxy ist umstritten, da:<br />
* HTTP-Header, wenn auch in geringem Umfang, verändert werden<br />
* Daten, wenn auch nicht direkt einsehbar, auf dem Gateway gespeichert werden<br />
* Daten nicht unmittelbar von der Originalquelle bezogen werden <br />
* Die Effizienzsteigerung gering ist. Nach Auswertung werden ca. 7% aller unverschlüsselten HTTP-Anfragen von dem Gateway direkt beantwortet. Für diese 7% halbiert sich der benötigte Traffic, wobei ein Großteil aller Webseiten heutzutage verschlüsselt wird und z.Zt. 50% des benötigten Traffics Overhead ist. <br />
* Zusätzliche Ressourcen (RAM, Prozessor) auf dem Gateway benötigt werden <br />
<br />
'''Inkompatiblität''': Die Konfiguration funktioniert z.Zt. nicht im Zusammenspiel mit der "OpenVPN Start/Stop Automatik" und dem automatischen OLSR Re-Routing des Default-Gateways (Dynamic Gateway Plugin).<br />
<br><br />
== Installation ==<br />
Installiert wird der de-facto-Standard squid:<br />
<code><br />
apt-get install squid3<br />
</code><br />
<br />
Für die kommende Konfiguration stoppen wir squid wieder:<br />
<code><br />
/etc/init.d/squid3 stop<br />
</code><br />
<br><br />
== Konfiguration ==<br />
Die mit installiere Konfigurationsdatei squid.conf ist sehr umfangreich und bietet eine gute Dokumentationsbasis, ist damit aber auch etwas unhandlich.<br />
<br />
Aus diesem Grund empfiehlt es sich, die Datei umzubenennen:<br />
<code><br />
mv /etc/squid3/squid.conf /etc/squid3/squid.conf.orig<br />
</code><br />
<br />
Wir importieren die Datei von einer Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/squid.conf -P /etc/squid3/<br />
</code><br />
<br />
Alternativ können wir die Datei auch leer erstellen:<br />
<code><br />
touch /etc/squid3/squid.conf<br />
</code><br />
<br />
Danach öffnen wir die Konfigurationsdatei...<br />
<code><br />
vi /etc/squid3/squid.conf<br />
</code><br />
<br />
...und füllen diese mit Inhalt, der allerdings noch auf das Gateway angepasst werden muss:<br />
<pre> <br />
# cache size in MB / no. of subdirectories / no. of subsubdirectories<br />
cache_dir ufs /var/spool/squid3 100 16 256<br />
<br />
#maximum object size in cache (default: 4 MB)<br />
#maximum_object_size 128 MB<br />
maximum_object_size 4 MB<br />
<br />
# Memory used for caching<br />
cache_mem 32 MB<br />
<br />
# No access log<br />
#access_log /var/log/squid3/access.log combined<br />
access_log none<br />
<br />
# Hostname shown in messages<br />
visible_hostname fff<br />
<br />
# Bind Squid to port ... and configure as transparent proxy <br />
http_port 3128 intercept<br />
# In addition a forward proxy is required<br />
http_port 3129<br />
<br />
refresh_pattern ^ftp: 1440 20% 10080<br />
refresh_pattern ^gopher: 1440 0% 1440<br />
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0<br />
refresh_pattern . 0 20% 4320<br />
<br />
# Allow connects from Freifunk Franken network<br />
acl fff src 10.50.0.0/16 <br />
<br />
# DNS by Freifunk-IP of localhost and Google DNS<br />
dns_nameservers 10.50.32.5 8.8.8.8<br />
<br />
# Bind outgoing address to Freifunk-Server IP to allow for VPN Routing <br />
tcp_outgoing_address 10.50.32.5<br />
udp_outgoing_address 10.50.32.5<br />
<br />
# Privacy options <br />
via off<br />
forwarded_for delete<br />
<br />
# standard http anonymizer<br />
request_header_access From deny all<br />
#request_header_access Referer deny all<br />
#request_header_access User-Agent deny all<br />
<br />
## paranoid http anonymizer<br />
#request_header_access Authorization allow all<br />
#request_header_access Proxy-Authorization allow all<br />
#request_header_access Cache-Control allow all<br />
#request_header_access Content-Length allow all<br />
#request_header_access Content-Type allow all<br />
#request_header_access Date allow all<br />
#request_header_access Host allow all<br />
#request_header_access If-Modified-Since allow all<br />
#request_header_access Pragma allow all<br />
#request_header_access Accept allow all<br />
#request_header_access Accept-Charset allow all<br />
#request_header_access Accept-Encoding allow all<br />
#request_header_access Accept-Language allow all<br />
#request_header_access Connection allow all<br />
#request_header_access All deny all<br />
<br />
# Access controls<br />
acl SSL_ports port 443 # https<br />
acl Safe_ports port 80 # http<br />
acl Safe_ports port 21 # ftp<br />
acl Safe_ports port 443 # https<br />
acl Safe_ports port 70 # gopher<br />
acl Safe_ports port 210 # wais<br />
acl Safe_ports port 1025-65535 # unregistered ports<br />
acl Safe_ports port 280 # http-mgmt<br />
acl Safe_ports port 488 # gss-http<br />
acl Safe_ports port 591 # filemaker<br />
acl Safe_ports port 777 # multiling http<br />
<br />
acl CONNECT method CONNECT<br />
http_access deny !Safe_ports<br />
http_access deny CONNECT !SSL_ports<br />
http_access allow localhost manager<br />
http_access deny manager<br />
http_access allow fff<br />
http_access allow localhost<br />
http_access deny all<br />
</pre><br />
<br />
Hier '''müssen''' angepasst werden:<br />
* cache_dir: Die Gesamtgröße des Caches (hier: 100 MByte) muss so bemessen sein, dass auf der Partition auch bei Maximalgröße des Caches noch Speicher frei bleibt. Squid Standardeinstellung ist 100 MB bei 16 Verzeichnissen und jeweils 256 Unterverzeichnissen. Freier Speicherplatz kann mit "df -h" ermittelt werden.<br />
* dns_nameservers: Hier sollten die '''Freifunk-IPv4''' des Gateways (in diesem Beispiel 10.50.32.5) und eine externe IP (hier Google DNS 8.8.8.8) eingetragen werden. Wichtig ist, '''nicht localhost''' einzutragen, da die Anfrage im Zusammenspiel mit der "outgoing address" (s.u.) über die fff-Routingtabelle laufen muss.<br />
* tcp_outgoing_address und udp_outgoing_address: Diese beide Einträge sind elementar wichtig. Zwar funktioniert der Proxy auch ohne, routet aber nicht über das VPN sondern direkt vom Gateway ins Internet. Damit die fff-Routingtabelle verwendet wird, für die als Default-Gateway eine VPN Verbindung eingerichtet ist, tragen wir hier die Freifunk-IP des Gateways ein (10.50.<irgendwas>). In diesem Beispiel ist die Freifunk-IPv4 des Gateways die 10.50.32.5.<br />
* access_log: Das Access log sollte deaktiviert bleiben (access_log none), da es ein lebendiges Beispiel für Vorratsdatenspeicherung ist und die log-Dateien auch sehr schnell, sehr groß werden.<br />
<br />
Danach erstellen wir die Verzeichnisstruktur des Proxy:<br />
<code><br />
squid3 -z<br />
</code><br />
<br />
Jetzt sind wir fast fertig. Wir starten den Proxy:<br />
<code><br />
/etc/init.d/squid3 start<br />
</code><br />
<br />
Anfragen, die auf Port 80 (http) reinkommen, müssen nun noch auf Port 3128 umgeleitet werden. Auf Port 3128 lauscht unser Proxy, http-Anfragen werden quasi transparent (oder zwangsweise) über den Proxy geleitet :<br />
<code><br />
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
</code><br />
<br />
Damit unsere Portumleitung mit jedem Start von Squid eingerichtet und mit jedem Stopp aufgehoben wird, pflegen wir sie (nicht ganz sauber) im squid start/stop Skript mit ein:<br />
<code><br />
vi /etc/init.d/squid3<br />
</code><br />
<br />
und fügen '''zwei''' iptables Einträge nach dem Start und vor dem Stopp von Squid ein:<br />
<pre><br />
.<br />
.<br />
.<br />
start () {<br />
cache_dir=`find_cache_dir cache_dir`<br />
cache_type=`grepconf cache_dir`<br />
<br />
#<br />
# Create run dir (needed for several workers on SMP)<br />
#<br />
create_run_dir<br />
<br />
#<br />
# Create spool dirs if they don't exist.<br />
#<br />
if test -d "$cache_dir" -a ! -d "$cache_dir/00"<br />
then<br />
log_warning_msg "Creating $DESC cache structure"<br />
$DAEMON -z -f $CONFIG<br />
fi<br />
<br />
umask 027<br />
ulimit -n 65535<br />
cd $cache_dir<br />
start-stop-daemon --quiet --start \<br />
--pidfile $PIDFILE \<br />
--exec $DAEMON -- $SQUID_ARGS < /dev/null<br />
# Use as transparent proxy<br />
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
return $?<br />
}<br />
<br />
stop () {<br />
PID=`cat $PIDFILE 2>/dev/null`<br />
# Use as transparent proxy<br />
iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
start-stop-daemon --stop --quiet --pidfile $PIDFILE --exec $DAEMON <br />
#<br />
# Now we have to wait until squid has _really_ stopped.<br />
#<br />
.<br />
.<br />
.<br />
</pre></div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Freifunk-Gateway_aufsetzen&diff=5358
Freifunk-Gateway aufsetzen
2016-01-23T13:04:19Z
<p>Green: /* OpenVPN Start/Stop Automatik */</p>
<hr />
<div>__TOC__<br />
[[Kategorie:Technik]]<br />
<br />
= Preface =<br />
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").<br />
<br />
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.<br />
<br />
Für Rat und Tat empfiehlt sich die Freifunk Franken Development Mailingliste.<br />
<br><br />
= Vorraussetzungen =<br />
* ssh-Zugang zum Server<br />
* Root Zugriff auf den Server. Entweder man ist "root" (Annahme in diesem Artikel) oder man kann Befehle mit "root-Rechten" durch ein vorgesetztes "sudo" ausführen sowie die Möglichkeit auf dem Server Kernelmodule zu laden (kann nicht jeder VServer!) <br />
* Grundlegende Netzwerkkenntnisse<br />
** IPv4 und Netzmaske<br />
** Devices<br />
** Routing (Default Route, Interfaces, Routing-Table) <br />
* Kentnisse <br />
** im Umgang mit Texteditoren (der im Artikel verwendete Editor kann durch beliebig andere ersetzt werden, z.B. durch "nano")<br />
** im Umgang mit der Linux Shell (z.B. Kommandozeilenparameter, Shell-Scripte, Umleitungen)<br />
** in der (selbständigen Nach-)Installation von (fehlenden) Software-Paketen<br />
** im Kompilieren von Software-Quellen<br />
<br><br />
= Referenzen / Andere Freifunk HowTo's =<br />
* http://wiki.freifunk.net/Freifunk_Hamburg/Gateway <br />
* http://wiki.mag.lab.sh/wiki/Freifunk_Fulda/Gateway<br />
<br><br />
= Anforderungen an Gateways =<br />
Die Anforderungen an das Gateway sind an sich niedrig. Wichtig ist, dass die Möglichkeit besteht, eigene Kernel-Module zu laden und das monatliche Traffic-Kontingent nicht zu niedrig ist. Entsprechend sind OpenVZ, Linux-vServer und ähnliche Containerlösungen nicht geeignet.<br />
<br />
Hardware:<br />
* CPU: 1x (64Bit)<br />
* RAM: 256MB .. 1GB<br />
* HDD: > 5 GB<br />
* NIC: 1x<br />
<br />
Software:<br />
* Debian Jessie (8) 64Bit Kernel <br />
* fastd v17<br />
* openvpn<br />
* B.A.T.M.A.N. adv 2013.4.0<br />
* dhcpd<br />
* olsr<br />
* bind9<br />
<br />
Pauschal gibt es keine Mindestanforderungen für den Trafficverbrauch. Es kommt sehr darauf an, wo der Server eingesetzt wird. <br />
'''Momentan suchen wir aber vor allem Server mit einem kostenlosen Traffic von mindestens 10-20 TB/Monat.'''<br />
<br><br />
== Anonymisierung (Störerhaftung) ==<br />
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.<br />
<br />
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. <br />
<br />
Folgende VPN-Anbieter sind zu diesem Zeitpunkt jedoch empfehlenswert:<br />
<br />
* [https://mullvad.net/en/ Mullvad] (Schweden, Niederlande)<br />
** Bis zu drei gleichzeitige Verbindungen<br />
** Kann man anonym mit Bitcoin bezahlen<br />
** Serverauswahl über die ausgelieferte OpenVPN-Konfiguration<br />
*** Server in den Niederlanden sind abends oft stark ausgelastet<br />
**(Gute Erfahrungen in Lübeck)<br />
<br />
* [https://integrityvpn.com/ Integrity VPN] (Schweden, Port80)<br />
** 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.<br />
**Hat eine überaus seriöse Webseite und eine Ltd. erfunden.™<br />
**Hat schon mal was von IPv6 gehört. Nutzt es zurzeit jedoch nur für SEO.<br />
**Blockiert Port 25 derzeit nicht.<br />
**Ist ein ein neuer Anbieter, der _bisher_ unausgelastet wirkt.<br />
** sind derzeit noch nicht nicht overselled und haben ihren Krams scheinbar halbwegs sauber konfiguriert<br />
<br />
* [https://ipredator.se/ Ipredator] (Schweden, Niederlande, Deutschland)<br />
** (Glänzen nicht durch Kompetenz, da sie lange Zeit nur PPTP angeboten haben)<br />
** Mögen schnelle Reconnects nicht -> manchmal muss man OpenVPN ein paar Stunden deaktivieren, bevor es wieder funktioniert.<br />
** Möchten bald auch IPv6 anbieten.<br />
** Angeblich Reseller von relakks<br />
<br />
Ungetestet:<br />
* [https://www.anonine.com/en Anonine VPN] (Portlane)<br />
* [https://privacy.io/ privacy.io] (Portlane)<br />
* [http://prq.se/?p=tunnel&intl=1 prq.se] (Eigenes Netz, teuer)<br />
* [http://arethusa.su/vpn.html Arethusa VPN] (Loggen in Frankreich, andere Server angeblich nicht)<br />
<br />
Einige Freifunknetze mieten auch VMs in Osteuropa. Da die VMs noch nicht an ihre Grezen stößt könnte man diese auch mitnutzen. Ansprechpartner wäre s0ma.<br />
<br><br />
== Anbindung an andere Netze ==<br />
Es gibt drei relativ relevante Netzwerke bei denen es sich lohnt, das lokale Netz damit zu verbinden:<br />
<br />
* InterCity-VPN zwischen den meisten Freifunknetzen<br />
** BGP<br />
** kleine Übsicht der http://www.ddmesh.de/topology/ic-vpn-verbindungen.html<br />
** Mehr Infos http://wiki.freifunk.net/IC-VPN<br />
<br />
* DN42<br />
** BGP<br />
** Experimentelles Darknet zur Erprobung von Routing-Technologien und so weiter, wird privat betrieben. Viel interessantes Zeugs™<br />
** 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.<br />
<br />
* ChaosVPN<br />
** Tinc<br />
** Relativ großes „Darknet“ zwischen vielen Hackerspaces auf der ganzen Welt.<br />
<br><br />
== vServer-Anbieter die empfehlenswert sind ==<br />
* [https://www.de-punkt.de/vserver.html de-punkt] (Databurg, FFM)<br />
** Schneller Speicher, gut bezahlbar, KVM, nur Traffic-Flat™® das übliche.<br />
* [http://www.hetzner.de/hosting/produktmatrix_vserver/vserver-produktmatrix Hetzner] (Falkenstein)<br />
** Bezahlbar, 6.90€/TB Extratraffic, KVM<br />
** Achtung: Die Netzwerkarte der VM ist aus Kompatibilitätsgründen auf e1000 gesetzt. Diese "Netzwerkkarte" kommt nicht mit den vielen UDP-Paketen von fastd zurecht. Deshalb muss man vor Verwendung als Gateway die Netzwerkkarte auf "virtio" stellen.<br />
* [http://colorhost.de/server/vserver/ colorhost] (über 23media, Global Switch, FFM)<br />
* Untersagt Nutzung für Freifunk (http://colorhost.de/server/vserver/kvm/small/)<br />
** Achtung: Nur Xen oder Xen HVM funktionieren<br />
* [http://www.xirra.net/en/v-server/productmatrix/ xirra] (Core-Backbone, NBG)<br />
** KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.<br />
* [http://buyvm.net/ BuyVM]<br />
** 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.<br />
* [http://webhod.de webhod]<br />
** 9,99 € für die kleinste KVM im Monat[https://www.webhod.de/de/vserver/kvm.html]<br />
<br><br />
== Server-Anbieter die '''nicht''' empfehlenswert sind ==<br />
* [http://www.wrzhost.com/ WRZhost]<br />
** 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.<br />
<br />
* [https://www.netcup.de/ netcup]<br />
** V-Server laufen zwar grundsätzlich gut, allerdings halten sie sich nicht an ihre Versprechungen. Server wurde bereits mehrfach gedrosselt obwohl der Traffic weit unter den versprochenen 80 Mbit/s war (zwischen 30 und 40 Mbit/s). Die Drosselung tritt ohne Vorwarnung in Kraft und man kann seinen Server nicht mehr erreichen. Entdrosselung nur auf Nachfrage und dann auch nur mit einigem hin und her.<br />
<br><br />
= Grundinstallation des Servers =<br />
Vom ausgesuchten Hoster lassen wir uns eine aktuelle Linux-Distribution installieren oder ausliefern, wobei sich die Anleitung auf ein Debian 8 / Jessie bezieht.<br />
<br><br />
== Repositories und Update ==<br />
Als erstes werfen wir einen Blick in...<br />
<br />
<code><br />
vi /etc/apt/sources.list<br />
</code><br />
<br />
...und schauen, inwieweit auf die gleichen Software-Repositories verwiesen wird:<br />
<br />
<pre> <br />
deb http://security.debian.org/ jessie/updates main<br />
deb-src http://security.debian.org/ jessie/updates main<br />
<br />
deb http://ftp.de.debian.org/debian/ jessie main contrib non-free<br />
deb-src http://ftp.de.debian.org/debian/ jessie main contrib non-free<br />
<br />
deb http://ftp.de.debian.org/debian/ jessie-updates main<br />
deb-src http://ftp.de.debian.org/debian/ jessie-updates main<br />
<br />
</pre><br />
<br />
Danach bringen wir das System auf einen aktuellen Stand:<br />
<br />
<code><br />
apt-get update<br />
<br />
apt-get upgrade<br />
</code><br />
<br><br />
== Sicherheit ==<br />
Den SSH-Zugang besser schützen durch:<br />
* Änderung des Ports<br />
* login nur mit key<br />
* Siehe [http://www.thomas-krenn.com/de/wiki/Absicherung_eines_Debian_Servers hier] für genaue Anleitung: <br />
<br />
<code><br />
apt-get install fail2ban<br />
</code><br />
<br />
und [http://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban_absichern einrichten]<br />
<br />
So,nun sollte der Server ausreichend abgesichert sein.<br />
<br><br />
== B.A.T.M.A.N. adv 2013.4.0 Kernel-Modul ==<br />
Batman-Adv aus Jessie ist zu neu. Hier muss manuell das alte B.A.T.M.A.N. advanced 2013.4.0 gebaut werden.<br />
<br />
Hierfür benötigen wir minimal die Paketquellen build-essential, linux-headers-amd64 und git:<br />
<br />
<code><br />
apt-get install build-essential linux-headers-amd64 git gnupg-curl<br />
</code><br />
<br />
Die Softwarequellen müssen heruntergeladen...<br />
<code><br />
cd ~<br />
<br />
git clone https://github.com/freifunk-gluon/batman-adv-legacy<br />
<br />
cd batman-adv-legacy<br />
</code><br />
<br />
... und kompiliert und installiert werden:<br />
<br />
<code><br />
make<br />
<br />
make install<br />
</code><br />
<br />
Hinweis: Sollten noch Paketquellen fehlen, wird dies während des Kompilierens gemeldet. Die Software-Quellen müssen nachinstalliert werden und der letzte Kompilierungs- und Installationsschritt so lange wiederholt werden, bis die Software erfolgreich erstellt wurde.<br />
<br />
Nach erfolgreicher Erstellung kann das B.A.T.M.A.N Kernel Modul per modprobe händisch eingebunden werden:<br />
<br />
<code><br />
modprobe batman-adv<br />
</code><br />
<br />
Es sollte dann im Kernel-log ....<br />
<code><br />
dmesg | grep batman_adv<br />
</code><br />
<br />
... mit einem Eintrag gelistet werden:<br />
<pre><br />
batman_adv: B.A.T.M.A.N. advanced 2013.4.0-21-ga854277-dirty (compatibility version 14) loaded<br />
</pre><br />
<br />
Das Kernelmodul von B.A.T.M.A.N. kann dann bei jedem Neustart des Systems geladen werden, indem in die Datei /etc/modules:<br />
<br />
<code><br />
vi /etc/modules<br />
</code><br />
<br />
..der Eintrag "batman-adv" hinzugefügt wird:<br />
<br />
<pre><br />
batman-adv<br />
</pre><br />
<br><br />
== B.A.T.M.A.N adv 2013.4.0 batctl ==<br />
Gleiches gilt für batctl, ein Kommandozeilenprogramm zur B.A.T.M.A.N Konfiguration. Die alte Version 2013.4.0 muss selber gebaut werden, da die Debian 8 / Jessie Paketquellen zu neu sind.<br />
<br />
Herunterladen und Entpacken der Softwarequellen:<br />
<code><br />
cd ~<br />
<br />
wget http://downloads.open-mesh.org/batman/releases/batman-adv-2013.4.0/batctl-2013.4.0.tar.gz<br />
<br />
tar xzf batctl-2013.4.0.tar.gz<br />
<br />
cd batctl-2013.4.0<br />
</code><br />
<br />
Kompilieren und Installieren:<br />
<br />
<code><br />
make<br />
<br />
make install<br />
</code><br />
<br />
Hinweis: Auch hier müssen ggf. fehlende Quellen händisch nachinstalliert und das Kompilieren und Installieren bis zum Erfolg wiederholt werden.<br />
<br><br />
== FastD ==<br />
Die Verbindung zwischen Gateway und Router wird über einen fastd-Tunnel realisiert.<br />
<br />
Hierfür müssen wir ein neues Repository in der Datei /etc/apt/sources.list deklarieren:<br />
<br />
<code><br />
vi /etc/apt/sources.list.d/universe-factory.list<br />
</code><br />
<br />
Dort fügen wir folgendes Repository an:<br />
<br />
<pre><br />
deb http://repo.universe-factory.net/debian/ sid main<br />
deb-src http://repo.universe-factory.net/debian/ sid main<br />
</pre><br />
<br />
Danach die PGP Schlüssel holen:<br />
<code><br />
gpg --keyserver hkps://hkps.pool.sks-keyservers.net --recv-key 16EF3F64CB201D9C<br />
<br />
gpg -a --export 16EF3F64CB201D9C | apt-key add -<br />
</code><br />
<br />
Datenbankupdate der Paketverwaltung:<br />
<code><br />
apt-get update<br />
</code><br />
<br />
Installation von fastd: <br />
<code><br />
apt-get install fastd <br />
</code><br />
<br><br />
<br />
== OpenVPN ==<br />
OpenVPN (falls benötigt) installieren wir mit:<br />
<code><br />
apt-get install openvpn<br />
</code><br />
<br><br />
== DHCP ==<br />
Den DHCP Server installieren wir mit:<br />
<code><br />
apt-get install isc-dhcp-server <br />
</code><br />
<br><br />
== Bind9 ==<br />
Als DNS Server nehmen wir hier den de-facto-Standard bind:<br />
<code><br />
apt-get install bind9 <br />
</code><br />
<br><br />
== OLSR ==<br />
Als Routing-Protokoll, um die einzelnen Hoods später zu einem Freifunk-Franken weit kommunizierenden Netz zu verbinden, wird OLSR installiert:<br />
<br />
<code><br />
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd_0.6.8.1-1_amd64.deb<br />
<br />
dpkg -i olsrd_0.6.8.1-1_amd64.deb<br />
<br />
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd-plugins_0.6.8.1-1_amd64.deb<br />
<br />
dpkg -i olsrd-plugins_0.6.8.1-1_amd64.deb<br />
<br />
</code><br />
<br><br />
= Konfigurieren des Freifunk-Gateways =<br />
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 />
<br><br />
== IPv4 des Gateways, IP-Bereich der Hood und DHCP Range des Gateway==<br />
Für das Gateway suchen wir uns unter [[Portal:Netz]] eine IPv4 Adresse aus dem statischen Range der Hood aus. Für Fürth läuft der Bereich für die statischen Adressen z.B. von 10.50.32.1 - 10.50.32.255. Hiervon suchen wir uns eine '''freie''' Adresse aus, und reservieren diese, indem wir sie weiter unten in die Tabelle der statischen IPs eintragen.<br />
<br />
Die Fürther Hood hat den IP-Bereich 10.50.32.0-10.50.32.255. Als Netzwerk wird dieser Bereich mit 10.50.32.0/21 deklariert, d.h. die ersten 21 Bit der IP identifizieren das Netzwerk "Fürther Hood" und die restlichen 11 Bit stehen zur IP Vergabe zur Verfügung, wobei Anfang (10.50.32.0) und Ende des Bereiches (10.50.39.255) reserviert sind und nicht, weder statisch noch dynamisch durch DHCP, belegt werden dürfen. Eine alternative Schreibweise zu 10.50.32.0/21 ist das Double "Network 10.50.32.0" und "Netmask 255.255.248.0". Ein entsprechender IP-Rechner zur analogen Anwendung in anderen Hoods findet sich z.B. [http://www.heise.de/netze/tools/netzwerkrechner/ hier].<br />
<br />
Ebenso sollte man einen DHCP-Bereich innerhalb des IP-Bereichs der jeweiligen Hood, die der GW bedienen soll, reservieren (d.h. in die oberer Tabelle unter [[Portal:Netz]] eintragen). Jeder DHCP-Server vergibt dynamisch IPv4 Adressen an Clients aus einem vorher definierten Adressbereich. Dieser Adressbereich sollte sich:<br />
* innerhalb des IP-Range der Hood bewegen<br />
* sich nicht mit dem Adressbereich überschneiden, den andere DHCP Server in der Hood verwalten<br />
* sich nicht mit dem Bereich der statischen Adressen der Hood überschneiden<br />
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. Vom gesamten IP-Bereich der Fürther Hood vergibt z.B. das Gateway fff-nue1 die Teilmenge 10.50.35.0 - 10.50.36.255 an Clients und teilt ihnen auf dem Weg auch gleich mit, wie sie Domain-Namen in IPs auflösen und auf welchem Weg sie ins Internet oder in andere Hoods kommen.<br />
<br><br />
== Routing Tabelle für Freifunk ==<br />
Fürs Routing im Freifunk Franken Netz wird eine eigene Routing Tabelle namens "fff" deklariert.<br />
<br />
Dies geschieht indem man in der Datei /etc/iproute2/rt_tables ...<br />
<code><br />
vi /etc/iproute2/rt_tables<br />
</code><br />
<br />
... folgendes am Ende einfügt:<br />
<br />
<pre><br />
10 fff<br />
</pre><br />
<br />
Unsere Freifunk Routing Tabelle lässt sich später durch<br />
<code><br />
ip route show table fff<br />
</code><br />
anzeigen, sobald wir die Tabelle mit Einträgen füllen.<br />
<br><br />
== B.A.T.M.A.N Netzwerk-Interface, fff Routingregeln und -tabelle ==<br />
'''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.<br />
<br />
In der Datei /etc/network/interfaces ...<br />
<br />
<code><br />
vi /etc/network/interfaces<br />
</code><br />
<br />
fügen wir zunächst folgenden Textblock des Gateways "klee" aus der Fürther Hood an:<br />
<br />
<pre><br />
.<br />
.<br />
.<br />
# device: bat0<br />
iface bat0 inet manual<br />
post-up ifconfig $IFACE up<br />
##Einschalten post-up:<br />
# IP des Gateways am B.A.T.M.A.N interface:<br />
post-up ip addr add 10.50.32.5/21 dev $IFACE<br />
# Regeln, wann die fff Routing-Tabelle benutzt werden soll: <br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.0.0.0/8 table fff <br />
post-up ip rule add to 10.0.0.0/8 table fff<br />
# Route in die Fuerther Hood: <br />
post-up ip route add 10.50.32.0/21 dev $IFACE table fff<br />
# Start des DHCP Servers:<br />
post-up invoke-rc.d isc-dhcp-server restart<br />
<br />
##Ausschalten post-down:<br />
# Loeschen von oben definieren Routen, Regeln und Interface: <br />
post-down ip route del 10.50.32.0/21 dev $IFACE table fff<br />
post-down ip rule del from 10.0.0.0/8 table fff<br />
post-down ip rule del to 10.0.0.0/8 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ifconfig $IFACE down<br />
<br />
# VPN Verbindung in die Fuerther Hood<br />
iface ffffuerthVPN inet manual<br />
post-up batctl -m bat0 if add $IFACE<br />
post-up ifconfig $IFACE up<br />
post-up ifup bat0<br />
post-down ifdown bat0<br />
post-down ifconfig $IFACE down<br />
</pre><br />
<br />
In diesem Beispiel sind:<br />
* IP des Gateway/Netzmaske der Fürther Hood: 10.50.32.5/21<br />
* IP des Netzwerks Fürther Hood / Netzmaske der Fürther Hood: 10.50.32.0/21.<br />
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.<br />
<br />
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.).<br />
<br />
Die Regeln definieren, das Traffic der<br />
* aus dem Netzwerk 10.0.0.0/8 kommt<br />
* das Netzwerk 10.0.0.0/8 zum Ziel hat<br />
* oder über die B.A.T.M.A.N Schnittstelle übermittelt wird<br />
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.<br />
<br />
Im post-down Abschnitt werden die vorher definierten Regeln, Interfaces und Routen wieder gelöscht.<br />
<br />
Der untere Abschnitt definiert einen VPN Tunnel in die Fürther Hood. Der Name des Interfaces im Beispiel (ffffuerthVPN) kann individuell neu vergeben werden.<br />
<br><br />
== FastD Start- und Verwaltungsscript ==<br />
Für die Konfiguration von fastd importieren wir eine Datei in ''/etc/fastd'' mit dem Befehl:<br />
<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/fff_beispiel_fastd.sh -P /etc/fastd/<br />
</code><br />
<br />
Alternativ kann das Skript aus einer leeren Datei erstellt werden:<br />
<code><br />
touch /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
danach öffnen wir diese:<br />
<br />
<code><br />
vi /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
und editieren das Skript oder fügen ein Neues ein:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
SERVERNAME="beispiel"<br />
<br />
hood="hoodeintragen"<br />
project="fff"<br />
port=10004<br />
<br />
SERVERNAME="$SERVERNAME.$hood"<br />
<br />
hostname=$SERVERNAME<br />
<br />
if [ ! -d /etc/fastd ]<br />
then<br />
mkdir /etc/fastd<br />
fi<br />
<br />
if [ ! -d /etc/fastd/$project.$hood ]<br />
then<br />
mkdir /etc/fastd/$project.$hood<br />
mkdir /etc/fastd/$project.$hood/peers<br />
<br />
#fastd config<br />
(<br />
echo "# Log warnings and errors to stderr"<br />
echo "log level error;"<br />
echo "# Log everything to a log file"<br />
echo "log to syslog as \"${project}${hood}\" level info;"<br />
echo "# Set the interface name"<br />
echo "interface \"${project}${hood}VPN\";"<br />
echo "# Support xsalsa20 and aes128 encryption methods, prefer xsalsa20"<br />
echo "#method \"xsalsa20-poly1305\";"<br />
echo "#method \"aes128-gcm\";"<br />
echo "method \"null\";"<br />
echo "# Bind to a fixed port, IPv4 only"<br />
echo "bind any:${port};"<br />
echo "# Secret key generated by \"fastd --generate-key\""<br />
echo "secret \"$(fastd --generate-key | grep -i Secret | awk '{print $2}')\";" <br />
echo "# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)" <br />
echo "# (see MTU selection documentation)" <br />
echo "mtu 1426;" <br />
echo "on up \"/etc/fastd/${project}.${hood}/up.sh\";" <br />
echo "on post-down \"/etc/fastd/${project}.${hood}/down.sh\";" <br />
echo "# Include peers from the directory 'peers'" <br />
echo "include peers from \"/etc/fastd/${project}.${hood}/peers\";" <br />
echo "secure handshakes no;"<br />
) >> "/etc/fastd/$project.$hood/$project.$hood.conf"<br />
<br />
#fastd-up<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifdown \$INTERFACE"<br />
) >> /etc/fastd/$project.$hood/down.sh<br />
<br />
chmod +x /etc/fastd/$project.$hood/down.sh<br />
<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifup \$INTERFACE" >> /etc/fastd/$project.$hood/up.sh<br />
) >> /etc/fastd/$project.$hood/up.sh<br />
chmod +x /etc/fastd/$project.$hood/up.sh<br />
fi<br />
<br />
pubkey=$(fastd -c /etc/fastd/$project.$hood/$project.$hood.conf --show-key --machine-readable)<br />
port=$(grep ^bind /etc/fastd/$project.$hood/$project.$hood.conf | cut -d: -f2 | cut -d\; -f1)<br />
<br />
# fire up<br />
if [ "$(/sbin/ifconfig -a | grep -i ethernet | grep ${project}${hood}VPN)" = "" ]<br />
then<br />
/bin/rm /var/run/fastd.$project.$hood.pid<br />
fastd -c /etc/fastd/$project.$hood/$project.$hood.conf -d --pid-file /var/run/fastd.$project.$hood.pid<br />
fi<br />
<br />
# register<br />
wget -T15 -q "http://keyserver.freifunk-franken.de/${project}/?name=$hostname&port=$port&key=$pubkey" -O /tmp/fastd_${project}.${hood}_output <br />
if [ "$?" != "0" ]<br />
then<br />
echo "Update failed"<br />
echo "Exiting, no clean up, no refresh"<br />
exit<br />
fi<br />
<br />
touch /tmp/fastd_${project}.${hood}_starting<br />
<br />
filenames=$(cat /tmp/fastd_${project}.${hood}_output| grep ^#### | sed -e 's/^####//' | sed -e 's/.conf//g')<br />
for file in $filenames<br />
do<br />
grep -A100 ^####$file.conf$ /tmp/fastd_${project}.${hood}_output | grep -v ^####$file.conf$ | grep -m1 ^### -B100 | grep -v ^### | sed 's/ float;/;/g' > "/etc/fastd/$project.$hood/peers/$file"<br />
echo 'float yes;' >> "/etc/fastd/$project.$hood/peers/$file"<br />
done<br />
<br />
#find old peers<br />
OLD=$(find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print)<br />
<br />
if [ -n "${OLD}" ] ; then<br />
echo "Lösche alte:"<br />
echo $OLD<br />
<br />
find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print | xargs /bin/rm /tmp/fastd_${project}.${hood}_starting<br />
fi<br />
<br />
#reload<br />
kill -HUP "$(cat /var/run/fastd.$project.$hood.pid)"<br />
<br />
exit 0<br />
</pre><br />
<br />
Zum Schluss geben wir noch ein<br />
<br />
<code><br />
chmod +x /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
ein, um das Skript ausführbar zu machen.<br />
<br />
Das Skript konfiguriert fastd, indem es<br />
* einen Schlüssel generiert, sollte keiner existieren<br />
* diesen Schlüssel mit dem Keyserver austauscht<br />
* die fastd Konfigurationsdatei anlegt<br />
* den fastd Dämonen startet<br />
<br />
Lediglich der Servername und die Hood müssen oben im Skript händisch angepasst werden. Der Dateiname des Skripts kann individuell angepasst werden.<br />
<br />
Nachdem das Script ausgeführt wurde, sollte man überprüfen ob das Interface in der Konfigurationsdatei unter /etc/fastd/fff.<Hoodname>/fff.<Hoodname>.conf das gleiche ist wie vorher in /etc/network/interfaces festgelegt. Wenn der Name nicht identisch ist (Groß-/Kleinschreibung), werden die Interfaces nicht starten.<br />
<br />
Hinweis: Das Gateway wird standardmässig in die Default-Hood eingebunden. Es wird hier lediglich ein Name für die Konfigurationsdatei und der Gateway Name definiert. Die Zuordnung des Gateways zu der Hood erfolgt später über den KeyXchange (siehe unten).<br />
<br><br />
== IP-Forwarding ==<br />
Um Anfragen, die das Gateway erreichen, weiterzuleiten, muss IP-Forwarding aktiviert werden. <br />
<br />
Manuell geht dies über:<br />
<code><br />
echo "1" > /proc/sys/net/ipv4/ip_forward<br />
<br />
echo "1" > /proc/sys/net/ipv6/conf/default/forwarding<br />
<br />
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding<br />
</code><br />
<br />
Dauerhaft lässt sich IP-Forwarding in /etc/sysctl.conf aktivieren:<br />
<code><br />
vi /etc/sysctl.conf<br />
</code><br />
<br />
.. um dort die Abschnitte einzukommentieren, die das Forwarding steuern:<br />
<pre><br />
.<br />
.<br />
.<br />
# Uncomment the next line to enable packet forwarding for IPv4<br />
net.ipv4.ip_forward=1<br />
<br />
# Uncomment the next line to enable packet forwarding for IPv6<br />
# Enabling this option disables Stateless Address Autoconfiguration<br />
# based on Router Advertisements for this host<br />
net.ipv6.conf.all.forwarding=1<br />
.<br />
.<br />
.<br />
</pre><br />
<br><br />
== Testen von B.A.T.M.A.N, fastd und Autostart ==<br />
Hierfür booten wir das Gateway am besten erst mal neu:<br />
<code><br />
reboot & exit<br />
</code><br />
<br />
und starten das fast.d Startskript manuell: <br />
<code><br />
/etc/fastd/fff_beispiel_fastd.sh &<br />
</code><br />
<br />
Beim Erststart werden Schlüsselpaare generiert und ausgetauscht, es kann also etwas dauern.<br />
<br />
Danach sollte der Aufruf von...<br />
<code><br />
pgrep fastd<br />
</code><br />
... mit der Prozess-ID beantwortet werden: Fastd läuft in dem Fall.<br />
<br />
<br />
Ein Aufruf von ifconfig:<br />
<code><br />
ifconfig<br />
</code><br />
<br />
sollte die neu erstellten Interfaces bat0 und ffffuerthVPN zurückliefern.<br />
Exemplarisch und als Auszug:<br />
<pre><br />
bat0 Link encap:Ethernet HWaddr ea:95:50:07:f7:27 <br />
inet addr:10.50.32.5 Bcast:0.0.0.0 Mask:255.255.248.0<br />
inet6 addr: fe80::e895:50ff:fe07:f727/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:1089992 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:849698 errors:0 dropped:1728 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0 <br />
RX bytes:141311612 (134.7 MiB) TX bytes:1052934594 (1004.1 MiB)<br />
<br />
.<br />
.<br />
.<br />
ffffuerthVPN Link encap:Ethernet HWaddr e6:3b:f3:b7:fc:db <br />
inet6 addr: fe80::e43b:f3ff:feb7:fcdb/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1426 Metric:1<br />
RX packets:32389694 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:2699525 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:500 <br />
RX bytes:4193328694 (3.9 GiB) TX bytes:1384843740 (1.2 GiB)<br />
.<br />
.<br />
.<br />
</pre><br />
Aus dem ifconfig Auszug für bat0 sollte die eingerichtete IP des Gateways und die Netzmaske hervorgehen.<br />
<br />
<br />
Die Abfrage der IP-Regeln:<br />
<code><br />
ip rule<br />
</code><br />
<br />
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):<br />
<pre><br />
32757: from all to 10.0.0.0/8 lookup fff <br />
32758: from 10.0.0.0/8 lookup fff <br />
32759: from all iif bat0 lookup fff <br />
</pre><br />
<br />
Eine Abfrage der fff-Routing Tabelle<br />
<code><br />
ip route show table fff <br />
</code><br />
<br />
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:<br />
<pre><br />
10.50.32.0/21 dev bat0 scope link<br />
</pre><br />
<br />
Ein Aufruf von "batctl o"<br />
<code><br />
batctl o <br />
</code><br />
<br />
ergibt eine Liste der MAC-Adressen von unseren nächsten Nachbarn. Exemplarisch und als Auszug:<br />
<pre><br />
[B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: ffffuerthVPN/e6:3b:f3:b7:fc:db (bat0)]<br />
Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ...<br />
96:43:c4:2e:73:68 0.004s (255) 96:43:c4:2e:73:68 [ffffuerthVPN]: 96:43:c4:2e:73:68 (255)<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
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:<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
Hier spendieren wir einen Eintrag, der fastd mit 10 Sekunden Verzögerung bei jedem Systemstart mitstartet:<br />
<pre><br />
# launch fastd with 10 seconds delay<br />
(sleep 10; sh /etc/fastd/fff_beispiel_fastd.sh) &<br />
</pre><br />
<br />
'''Zusätzlich''' muss ein Cronjob angelegt werden, der das Skript z.B. alle 10 Minuten ausführt:<br />
<code><br />
crontab -e<br />
</code><br />
<br />
Nun folgendes eingeben:<br />
<pre><br />
*/10 * * * * sh /etc/fastd/fff_beispiel_fastd.sh<br />
</pre><br />
<br />
und<br />
<br />
<code><br />
/etc/init.d/cron restart<br />
</code><br />
<br><br />
== OpenVPN-Tunnel einrichten ==<br />
Die Einrichtung eines OpenVPN Tunnels kann von Anbieter zu Anbieter variieren. <br />
Im Laufe der Zeit sollte die Dokumentation so um funktionierende Konfigurationen verschiedener Anbieter erweitert werden.<br />
<br><br />
=== Mullvad ===<br />
Mullvad liefert in der Datei mullvadconfig.zip, die notwendigen Schlüssel (ca.crt, mullvad.crt, mullvad.key) als auch eine Konfigurationsdatei (mullvad_linux.conf) mit, die später angepasst werden muss.<br />
<br />
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:<br />
<br />
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.<br />
<br />
Als unverbindliche Richtschnur für Linux:<br />
<code><br />
scp mullvadconfig.zip root@<ipv4 des Gateways>:/root<br />
</code><br />
<br />
Danach loggen wir uns auf dem Gateway ein und entpacken die Datei (nicht vergessen unzip zu installieren):<br />
<code><br />
ssh root@<ipv4 des Gateways><br />
<br />
unzip mullvadconfig.zip<br />
<br />
cd <Kundennummernverzeichnis><br />
<br />
cp * /etc/openvpn<br />
</code><br />
<br />
''/etc/openvpn/'' sollte mit dem Inhalt des entpackten mullvadconfig.zip Archivs dann so aussehen:<br />
<pre><br />
ca.crt crl.pem mullvad.crt mullvad.key mullvad_linux.conf mullvad-up mullvad_windows.conf.ovpn <br />
</pre><br />
<br />
'''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.<br />
<br />
Wir legen ein benutzerspezifisches start-up Script namens mullvad-up an:<br />
<code><br />
vi /etc/openvpn/mullvad-up<br />
</code><br />
<br />
und füllen sie mit folgendem Inhalt:<br />
<pre><br />
#!/bin/bash<br />
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE<br />
</pre><br />
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.<br />
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.<br />
<br />
Das Skript mullvad-up muss ferner ausführbar sein:<br />
<code><br />
chmod +x /etc/openvpn/mullvad-up<br />
</code><br />
<br />
Dieses spezifische Routing muss zwingend in mullvad_linux.conf eingepflegt werden:<br />
<code><br />
vi /etc/openvpn/mullvad_linux.conf<br />
</code><br />
<br />
und hier die Konfiguration entsprechend geändert werden:<br />
<pre><br />
.<br />
.<br />
.<br />
# Allow calling of built-in executables and user-defined scripts.<br />
script-security 2<br />
<br />
# Parses DHCP options from openvpn to update resolv.conf<br />
#up /etc/openvpn/update-resolv-conf<br />
#down /etc/openvpn/update-resolv-conf<br />
<br />
# Enable Freifunk specific Routing<br />
route-noexec<br />
route-delay 3<br />
route-up /etc/openvpn/mullvad-up<br />
.<br />
.<br />
.<br />
</pre><br />
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.<br />
<br />
Wer möchte, kann in mullvad_linux.conf auch Länder definieren, über die der VPN Traffic laufen soll (Ein- /Auskommentieren).<br />
<br />
Der openvpn Tunnel kann nun testweise gestartet werden:<br />
<code><br />
cd /etc/openvpn<br />
<br />
/usr/sbin/openvpn mullvad_linux.conf &<br />
</code><br />
<br />
und sollte exemplarisch und im Auszug folgendes zurück liefern:<br />
<pre><br />
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<br />
Sun Sep 6 12:45:20 2015 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08<br />
Sun Sep 6 12:45:20 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts<br />
.<br />
.<br />
.<br />
Sun Sep 6 12:45:23 2015 /sbin/ip link set dev tun0 up mtu 1500<br />
Sun Sep 6 12:45:23 2015 /sbin/ip addr add dev tun0 10.114.0.45/16 broadcast 10.114.255.255<br />
Sun Sep 6 12:45:23 2015 /sbin/ip -6 addr add fdef:e287:a479:72::102b/112 dev tun0<br />
Sun Sep 6 12:45:23 2015 /etc/openvpn/mullvad-up tun0 1500 1558 10.114.0.45 255.255.0.0 init<br />
Sun Sep 6 12:45:23 2015 Initialization Sequence Completed<br />
</pre><br />
Wichtig ist hierbei, dass in der vorletztes Zeile unser Freifunk-spezifisches Routing durchgeführt wird.<br />
<br />
Das VPN-Gateway sollte nun als Default Route in der fff-Routingtabelle auftauchen:<br />
<code><br />
ip route show table fff | grep default<br />
</code><br />
<br />
Exemplarisch wäre eine Ausgabe für das Tunnel-Device tun0 und dem VPN-Gateway 10.114.0.1:<br />
<pre><br />
default via 10.114.0.1 dev tun0<br />
</pre><br />
<br />
Auch ein ifconfig Eintrag für das Tunnel Device...<br />
<code><br />
ifconfig<br />
</code><br />
<br />
...sollte jetzt existieren (Exemplarisch und im Auszug):<br />
<pre><br />
.<br />
.<br />
.<br />
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 <br />
inet addr:10.114.0.76 P-t-P:10.114.0.76 Mask:255.255.0.0<br />
inet6 addr: fdad:bdef:735d:72::104a/112 Scope:Global<br />
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1<br />
RX packets:1012476 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:640206 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:100 <br />
RX bytes:1250196616 (1.1 GiB) TX bytes:84979294 (81.0 MiB)<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
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:<br />
<code><br />
vi /etc/rc.local <br />
</code><br />
<br />
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:<br />
<pre><br />
# launch vpn with 5 seconds delay<br />
(sleep 5; /usr/sbin/openvpn /etc/openvpn/mullvad_linux.conf >> /var/log/mullvad_vpn.log &) &<br />
</pre><br />
<br><br />
<br />
=== NordVPN ===<br />
NordVPN liefert die Datei config.zip mit, die für jeden verwendbaren VPN-Server eine seperate Konfigurationsdatei enthält.<br />
<br />
'''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.<br />
<br />
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.<br />
<br />
Als unverbindliche Richtschnur für Linux:<br />
<code><br />
scp config.zip root@<ipv4 des Gateways>:/root<br />
</code><br />
<br />
Und entpacken diese auf dem Gateway:<br />
<code><br />
cd ~<br />
<br />
mkdir nordvpn-configs<br />
<br />
mv config.zip nordvpn-configs<br />
<br />
cd nordvpn-configs<br />
<br />
unzip config.zip<br />
</code><br />
<br />
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.<br />
<br />
Im Beispiel nehmen wir se1.nordvpn.com.udp1194.ovpn und passen Sie zunächst Freifunk-spezifisch an (siehe Aussperr-Hinweis oben):<br />
<br />
<code><br />
vi se1.nordvpn.com.udp1194.ovpn<br />
</code><br />
<br />
Ä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:<br />
<pre><br />
.<br />
.<br />
.<br />
# Provide Username and Password<br />
auth-user-pass /etc/openvpn/nordvpn-pw<br />
.<br />
.<br />
.<br />
# Allow calling of built-in executables and user-defined scripts.<br />
script-security 2<br />
<br />
# Enable Freifunk specific Routing<br />
route-noexec<br />
route-delay 3<br />
route-up /etc/openvpn/nordvpn-up<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
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:<br />
<code><br />
cp se1.nordvpn.com.udp1194.ovpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf<br />
</code><br />
<br />
Hier legen wir noch unser Freifunk Startskript und unsere Password Datei an und machen das Skript ausführbar:<br />
<code><br />
touch /etc/openvpn/nordvpn-up<br />
<br />
touch /etc/openvpn/nordvpn-pw<br />
<br />
chmod +x /etc/openvpn/nordvpn-up<br />
</code><br />
<br />
Man öffnet nordvpn-up...<br />
<code><br />
vi /etc/openvpn/nordvpn-up<br />
</code><br />
<br />
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):<br />
<pre><br />
#!/bin/bash<br />
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE<br />
</pre><br />
<br />
Nun öffnet man nordvpn-pw:<br />
<code><br />
vi /etc/openvpn/nordvpn-pw<br />
</code><br />
<br />
Und legt in der ersten Zeile der Datei seinen NordVPN Usernamen und in der zweiten Zeile sein NordVPN Passwort ab:<br />
<pre><br />
(Username bei NordVPN)<br />
(Password bei NordVPN)<br />
</pre><br />
<br />
Der Tunnel kann nun testweise gestartet werden (hier im Beispiel mit der Konfigurationsdatei se1.nordvpn.com.udp1194.ovpn)<br />
<code><br />
openvpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf &<br />
</code><br />
<br />
Und sollte aufgebaut werden:<br />
<pre><br />
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<br />
.<br />
.<br />
.<br />
Sun Sep 27 09:07:15 2015 /sbin/ip link set dev tun0 up mtu 1500<br />
Sun Sep 27 09:07:15 2015 /sbin/ip addr add dev tun0 local 10.8.8.226 peer 10.8.8.225<br />
Sun Sep 27 09:07:18 2015 Initialization Sequence Completed<br />
</pre><br />
<br />
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:<br />
<code><br />
vi /etc/rc.local <br />
</code><br />
<br />
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:<br />
<pre><br />
# launch vpn with 5 seconds delay<br />
(sleep 5; cd /etc/openvpn ; /usr/sbin/openvpn se1.nordvpn.com.udp1194.ovpn.conf >> /var/log/nordvpn.log &) &<br />
</pre><br />
Die Beispiel-Konfigurationsdatei (se1.nordvpn.com.udp1194.ovpn.conf) muss entsprechend angepasst werden.<br />
<br><br />
== DNS Server ==<br />
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.<br />
<br />
----<br />
<br />
'''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.'''<br />
<br />
----<br />
<br />
Hierfür editieren wir die Datei named.conf.options...<br />
<code><br />
vi /etc/bind/named.conf.options<br />
</code><br />
<br />
...und tragen die DNS Server, die wir anfragen wollen, wenn wir die Information nicht selber haben, als forwarders ein:<br />
<pre><br />
.<br />
.<br />
.<br />
forwarders {<br />
10.50.32.1;<br />
10.50.32.2;<br />
8.8.8.8;<br />
};<br />
allow-query { <br />
127.0.0.1/8; <br />
10.0.0.0/8; <br />
};<br />
.<br />
.<br />
. <br />
</pre><br />
In diesem Fall werden die Freifunk Gateways ro1 (10.50.32.1) und fff-nue1 (10.50.32.2) der Fürther Hood als auch Google DNS (8.8.8.8) als Forwarders definiert. Für andere Hoods muss die lokale Adresse der Freifunk DNS Server unter [[Portal:Netz]] ermittelt werden (z.B. 10.50.48.1 für ro1 in der Ansbacher Hood).<br />
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".<br />
<br />
Neustart des DNS-Servers mit der neuen Konfiguration:<br />
<code><br />
/etc/init.d/bind9 restart<br />
</code><br />
<br />
Testen können wir, indem wir vom DNS Server des Gateways (localhost/127.0.0.1) eine DNS-Auflösung abfragen. <br />
<br />
Ein DNS Resolve für freifunk-franken.de ...<br />
<code><br />
dig @127.0.0.1 freifunk-franken.de<br />
</code><br />
<br />
...sollte von uns selber (Server localhost; 127.0.0.1) beantwortet werden:<br />
<pre><br />
;; global options: +cmd<br />
<br />
;; Got answer:<br />
<br />
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5819<br />
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1 <br />
;; OPT PSEUDOSECTION:<br />
; EDNS: version: 0, flags:; udp: 4096<br />
<br />
;; QUESTION SECTION:<br />
;freifunk-franken.de. IN A<br />
;; ANSWER SECTION:<br />
freifunk-franken.de. 3599 IN A 31.172.113.113 <br />
.<br />
. <br />
.<br />
;; Query time: 117 msec<br />
;; SERVER: 127.0.0.1#53(127.0.0.1)<br />
;; WHEN: Tue Sep 08 14:16:32 EEST 2015<br />
;; MSG SIZE rcvd: 275<br />
</pre><br />
<br><br />
<br />
== B.A.T.M.A.N Gateway Selection ==<br />
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.<br />
<br />
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:<br />
* Bandbreite der Netzanbindung (z.B. 100 Mbit/sec, gesplittet in 50 Mbit/sec up/down)<br />
* 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)<br />
* Erfahrungswerten / eigenes Ermessen<br />
* Bandbreite, bei dem der Gateway Prozessor ausgelastet ist<br />
<br />
Eventuell muss zuerst bc nachinstalliert werden, falls nicht vorhanden:<br />
<code><br />
apt-get install bc<br />
</code><br />
<br />
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.<br />
<br />
Importieren des Skripts aus einer Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/dyn_announce_gw_bw.sh -P /usr/local/bin/<br />
</code><br />
<br />
Alternativ kann das Skript auch als leere Datei erstellt werden:<br />
<code><br />
touch /usr/local/bin/dyn_announce_gw_bw.sh<br />
</code><br />
<br />
Wir machen das Skript ausführbar und öffnen die Datei:<br />
<code><br />
chmod +x /usr/local/bin/dyn_announce_gw_bw.sh<br />
<br />
vi /usr/local/bin/dyn_announce_gw_bw.sh<br />
</code><br />
<br />
Und Füllen dieses mit Inhalt oder editieren den importierten Inhalt:<br />
<pre><br />
#!/bin/bash<br />
gwsel_lockfile="/tmp/gwsel_lockfile" # lockfile to allow for low bandwidth settings <br />
<br />
if [ -z "$1" ]; then<br />
echo<br />
echo "usage: $0 <network-interface> <update_interval [sec]> <total BW up [Mbit/sec]> <total BW down [Mbit/sec]>"<br />
echo<br />
echo "e.g. $0 eth0 60 10 10"<br />
echo<br />
exit<br />
fi<br />
<br />
while true<br />
do<br />
if [ ! -e ${gwsel_lockfile} ]; then # lockfile not present<br />
# Bandwidth currently used (time averaged)<br />
R1=$(cat "/sys/class/net/$1/statistics/rx_bytes")<br />
T1=$(cat "/sys/class/net/$1/statistics/tx_bytes")<br />
sleep "$2"<br />
R2=$(cat "/sys/class/net/$1/statistics/rx_bytes")<br />
T2=$(cat "/sys/class/net/$1/statistics/tx_bytes")<br />
TkbitPS=$(echo "scale=0; ($T2 - $T1) / 1024 * 8 / $2" | bc -l)<br />
RkbitPS=$(echo "scale=0; ($R2 - $R1) / 1024 * 8 / $2" | bc -l)<br />
# echo "BW used -- up $1: $TkbitPS kBit/s; down $1: $RkbitPS kBit/s"<br />
<br />
# Remaining bandwidth available; cut-off negative values<br />
Tavail_kbitPS=$(echo "scale=0; if (($3 * 1024 - $TkbitPS) >0) ($3 * 1024 - $TkbitPS) else 0" | bc -l)<br />
Ravail_kbitPS=$(echo "scale=0; if (($4 * 1024 - $RkbitPS) >0) ($4 * 1024 - $RkbitPS) else 0" | bc -l)<br />
# echo "BW available -- up $1: $Tavail_kbitPS kBit/s; down $1: $Ravail_kbitPS kBit/s"<br />
else # lockfile present<br />
Tavail_kbitPS=0<br />
Ravail_kbitPS=0<br />
sleep "$2"<br />
fi<br />
<br />
for bat in /sys/class/net/bat*; do<br />
iface=${bat##*/}<br />
batctl -m $iface gw_mode server "${Ravail_kbitPS}kbit/${Tavail_kbitPS}kbit" <br />
done<br />
done<br />
</pre><br />
<br />
Das Skript übernimmt als Parameter:<br />
* Netzwerkinterface, das es zu überwachen gilt (i.d.R. eth0)<br />
* 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)<br />
* Upload Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)<br />
* Download Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)<br />
<br />
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 olsr Defaultroute mit geringer Bandbreite verfügbar ist.<br />
<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.:<br />
<code><br />
/usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10<br />
</code><br />
<br />
Um die Gateway Selection beim Systemsstart zu aktivieren, können wir das Skript z.B. in rc.local aufrufen:<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
um dort, leicht zeitverzögert, o.a. Befehl einzupflegen, wobei die Parametrisierung noch Gateway-spezifisch angepasst werden muss:<br />
<pre><br />
.<br />
.<br />
.<br />
#enable batman GW selection with 15 seconds delay<br />
(sleep 15; /usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10) &<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
ACHTUNG! Bei mehreren bat Interfaces (weil man in mehreren Hoods Gateway ist) muss diese Einstellung für jedes Gateway gesetzt werden, hier muss das Script unbedingt überarbeitet werden!<br />
<br />
<pre><br />
batctl -m $batX gw_mode xxmbit/xxmbit<br />
</pre><br />
<br />
und dies für jedes batX Interface. Das Script muss daraufhin noch angepasst werden.<br />
<br />
<br />
auf den Routern kann der vorselektierte Gateway mit <br />
<br />
<code><br />
batctl gwl<br />
</code><br />
<br />
angeguckt werden. Ich vermute das der Gateway mit den Pfeil vorne der vorselektierte Gateway ist, allerdings machen erste beobachtete Daten bisher in meinen Augen noch keinen wirklichen Sinn.<br />
<br><br />
<br />
== DHCP Server ==<br />
Die DHCP Konfiguration kann schon mal vorbereitet werden, sollte aber erst mit als letzter Schritt scharf geschaltet werden. Ein DHCP-Server, der Clients nicht funktionierende DNS-Server oder ein nicht funktionierendes Gateway mitteilt, sperrt diese aus dem Freifunk Netz aus.<br />
<br />
In isc-dhcp-server definieren wir ...<br />
<code><br />
vi /etc/default/isc-dhcp-server<br />
</code><br />
<br />
... das der DHCP Server für das B.A.T.M.A.N Device Anfragen beantworten soll:<br />
<pre><br />
.<br />
.<br />
<br />
INTERFACES="bat0"<br />
.<br />
.<br />
</pre><br />
<br />
Nachfolge Konfiguration wird in auskommentierter Form vorbereitet und sollte erst im letzten Schritt durch Einkommentieren und durch einen Neustart des DHCP Servers...<br />
<code><br />
/etc/init.d/isc-dhcp-server restart<br />
</code><br />
...aktiviert werden.<br />
<br />
Die Konfiguration wird in dhcpd.conf vorgenommen:<br />
<code><br />
vi /etc/dhcp/dhcpd.conf<br />
</code><br />
<br />
und folgender Konfigurationsblock zunächst auskommentiert eingefügt, wobei Gateway und Hood spezifische Änderungen noch eingepflegt werden müssen:<br />
<pre><br />
.<br />
.<br />
.<br />
### Freifunk Franken<br />
#option domain-name "fff.community";<br />
#option domain-name-servers 10.50.16.1;<br />
#authoritative;<br />
### Fuerth<br />
#subnet 10.50.32.0 netmask 255.255.248.0 { # Netzwerk und Netzmaske der Fuerther Hood<br />
# range 10.50.38.0 10.50.39.254; # IP-Range die der DHCP-Server innerhalb der Fuerther Hood verwaltet <br />
# option routers 10.50.32.5; # Default-Gateway, dass Clients mitgeteilt wird <br />
# option domain-name-servers 10.50.32.5, 10.50.32.1; # Name-Server, die Clients mitgeteilt werden<br />
#}<br />
</pre><br />
<br />
Netzwerk und Netzmaske müssen derjenigen der Hood des Gateways entsprechen. Im Beispiel ist dies Fürth, für z.B. Hassberge hieße der Eintrag "subnet 10.50.56.0 netmask 255.255.252.0".<br />
<br />
Der IP-Bereich (Range), die der DHCP-Server in der Hood verwaltet, wurde zuvor unter [[Portal:Netz]] reserviert.<br />
<br />
Unter Routers wird den Clients das Default-Gateway mitgeteilt: Das Gateway, über das Clients das Internet oder eine andere Hood erreichen. In unserem Beispiel routet das aufgesetzte Gateway selber via VPN ins Internet oder via olsr (später) in andere Hoods. Als Default-Gateway wird also die eigene statische IP des Gateways, aus der eigenen Hood, die in [[Portal:Netz]] reserviert wurde, verwendet.<br />
<br />
Ähnlich verhält es sich mit den Nameservern: Auf unserem Gateway wurde ein DNS Server eingerichtet, also kann der domain-name-server unser eigenes Gateway, mit der reservierten statische IP aus der Hood, wie in [[Portal:Netz]], sein. Als Backup empfiehlt sich ein weiterer DNS-Server aus der Hood, in unserem Beispiel ro1 in der Fürther.<br />
<br><br />
<br />
== GRE-Tunnel zu anderen Gateways ==<br />
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]].<br />
<br />
Der GRE-Tunnel wird in /etc/network/interfaces...<br />
<code><br />
vi /etc/network/interfaces<br />
</code><br />
<br />
...mit folgenden noch auf das Gateway anzupassenden Einträgen deklariert:<br />
<pre><br />
auto <tunnel><br />
iface <tunnel> inet static<br />
address <Eigene IPv4 (Freifunk Netz)><br />
pre-up ip -4 tunnel add $IFACE mode gre local <Eigene IPv4 (Internet)> remote <IPv4 des Tunnelpartners (Internet)> ttl 255<br />
#pre-up ip -6 tunnel add $IFACE mode ip6gre local <Eigene IPv6 (Internet)> remote <IPv6 des Tunnelpartners (Internet)> ttl 255<br />
<br />
up ifconfig $IFACE multicast<br />
pointopoint <IPv4 des Tunnelpartners (Freifunk Netz)><br />
post-up iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu<br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.50.0.0/16 table fff<br />
post-up ip rule add to 10.50.0.0/16 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ip rule del from 10.50.0.0/16 table fff<br />
post-down ip rule del to 10.50.0.0/16 table fff<br />
post-down iptables -t mangle -D POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu<br />
post-down iptunnel del $IFACE<br />
</pre><br />
<br />
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.<br />
<br />
'''Beispiel:''' <br />
Um als fff-nue1 einen Tunnel zu ro1 aufzubauen, können die IP-Adressen wie folgt gewählt werden:<br />
<pre><br />
<tunnel> ro1<br />
<Eigene IPv4 (Freifunk Netz)> fff-nue1 10.50.252.1<br />
<IPv4 des Tunnelpartners (Freifunk Netz)> ro1 10.50.252.0<br />
<Eigene IPv4 (Internet)> fff-nue1 31.172.33.99<br />
<IPv4 des Tunnelpartners (Internet)> ro1 176.126.221.7<br />
</pre><br />
<br />
In der Partnerkonfiguration für ro1 werden die Rollen entsprechend vertauscht:<br />
<pre><br />
<tunnel> fff-nue1<br />
<Eigene IPv4 (Freifunk Netz)> ro1 10.50.252.0<br />
<IPv4 des Tunnelpartners (Freifunk Netz)> fff-nue1 10.50.252.1<br />
<Eigene IPv4 (Internet)> ro1 176.126.221.7<br />
<IPv4 des Tunnelpartners (Internet)> fff-nue1 31.172.33.99 <br />
</pre><br />
<br />
Der Tunnel kann über den Aufruf von<br />
<code><br />
ifup <tunnel><br />
</code><br />
...aufgebaut werden, wobei <tunnel> der Name des GRE-Interfaces ist (im Beispiel ro1)<br />
<br />
Nach Aufruf von ifconfig..<br />
<code><br />
ifconfig <br />
</code><br />
sollten wir einen Eintrag für den Tunnel (in diesem Beispiel ro1) vorfinden:<br />
<pre><br />
.<br />
.<br />
.<br />
ro1 Link encap:UNSPEC HWaddr B0-7B-1C-73-30-30-3A-35-00-00-00-00-00-00-00-00 <br />
inet addr:10.50.252.1 P-t-P:10.50.252.0 Mask:255.255.255.255<br />
inet6 addr: fe80::200:5efe:b07b:1c73/64 Scope:Link<br />
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1476 Metric:1<br />
RX packets:160913 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:146654 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0 <br />
RX bytes:66984353 (63.8 MiB) TX bytes:10675001 (10.1 MiB)<br />
.<br />
.<br />
.<br />
</pre><br />
<br><br />
== OLSR ==<br />
=== Basiskonfiguration ===<br />
Mittels OLSR können die Gateways selbstständig Routinginformationen austauschen. Ähnlich wie B.A.T.M.A.N einzelne Router innerhalb einer Hood vermesht (Level 2 Netz), handelt es sich bei olsr um ein mesh zwischen den Gateways (Level 3). Es ermöglicht ein Freifunk Franken internes Routing: z.B. kann eine beliebige IPv4 aus der Nürnberger Hood aus der Fürth Hood heraus erreicht werden.<br />
<br />
Vorlagen können unter Sicherung der Originaldateien wie folgt importiert werden:<br />
<code><br />
mv /etc/default/olsrd /etc/default/olsrd.orig<br />
<br />
mv /etc/olsrd/olsrd.conf /etc/olsrd/olsrd.conf.orig<br />
<br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd -P /etc/default/<br />
<br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd.conf -P /etc/olsrd/<br />
</code><br />
<br />
Zunächst zeigen wir die Interfaces an, unter dem wir olsr Routing Informationen austauschen:<br />
<code><br />
vi /etc/default/olsrd<br />
</code><br />
<br />
Im Beispiel wird über die 2 GRE-Tunnel nue1 und ro1 ausgetauscht, dies muss entsprechend der GRE-Tunnel Konfiguration angepasst werden: <br />
<pre><br />
.<br />
.<br />
#<br />
# Uncomment the next line run olsrd automatically at startup<br />
#<br />
START_OLSRD="YES"<br />
<br />
#<br />
# Uncomment the next line to force-configure the wifi interface to be setup<br />
# for ad-hoc mode using the /usr/sbin/olsrd-adhoc-setup script whenever olsrd<br />
# is started.<br />
#<br />
SETUP_ADHOC="NO"<br />
.<br />
.<br />
.<br />
#<br />
# Specify the network interfaces that olsrd will run on, this will most likely<br />
# be your wifi interface.<br />
#<br />
MESH_IF="nue1 ro1" <br />
.<br />
.<br />
</pre><br />
<br />
<br />
Weiter wird dann hier ...<br />
<code><br />
vi /etc/olsrd/olsrd.conf<br />
</code><br />
... konfiguriert. <br />
Da unser Beispiel-Gateway ins Netz der Fürther Hood eingebunden ist, teilen wir dies andern Gateways über den Eintrag 10.50.32.0/21 mit:<br />
<pre><br />
.<br />
.<br />
.<br />
# HNA IPv4 routes<br />
# syntax: netaddr netmask<br />
# Example Internet gateway:<br />
# 0.0.0.0 0.0.0.0<br />
<br />
Hna4<br />
{<br />
# Internet gateway:<br />
# 0.0.0.0 0.0.0.0<br />
# more entries can be added:<br />
# 192.168.1.0 255.255.255.0<br />
10.50.32.0/21<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Hier wird das olsr Webinterface auf port 8080 konfiguriert:<br />
<br />
<pre><br />
.<br />
.<br />
.<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
# defaults to 1978<br />
PlParam "Port" "8080"<br />
# if you dont set these, the default is to listen only on the loopback device<br />
#PlParam "Host" "80.23.53.22"<br />
#PlParam "Net" "10.0.0.0 255.0.0.0"<br />
PlParam "Net" "0.0.0.0 0.0.0.0"<br />
#PlParam "Host" "127.0.0.1"<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Ferner wird der VPN-Tunnel (hier tun0) per persönlich angepasstem ping Kommando auf sein Funktion hin überwacht. Sollte der VPN-Tunnel ausfallen, ermöglicht olsr im Zusammenspiel mit der Routing Priorisierung (s.u) und der OpenVPN Start-/Stop Automatik (s.u.) ein automatisches Re-Routing:<br />
<pre><br />
.<br />
.<br />
.<br />
LoadPlugin "olsrd_dyn_gw.so.0.5"<br />
{<br />
# Here parameters are set to be sent to the<br />
# plugin. Theese are on the form "key" "value".<br />
# Parameters ofcause, differs from plugin to plugin.<br />
# Consult the documentation of your plugin for details.<br />
<br />
# Example: dyn_gw params<br />
<br />
# how often to check for Internet connectivity<br />
# defaults to 5 secs<br />
PlParam "Interval" "5"<br />
<br />
# if one or more IPv4 addresses are given, do a ping on these in<br />
# descending order to validate that there is not only an entry in<br />
# routing table, but also a real internet connection. If any of<br />
# these addresses could be pinged successfully, the test was<br />
# succesful, i.e. if the ping on the 1st address was successful,the<br />
# 2nd won't be pinged<br />
PlParam "Ping" "8.8.8.8"<br />
PlParam "Ping" "82.165.230.17"<br />
PlParam "pingcmd" "ping -c 1 -q -I tun0 %s"<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Folgender Konfigurationsblock muss ans Ende der Konfigurationsdatei angefügt werden. Es ermöglich olsr die Manipulation der fff-Routingtabelle:<br />
<pre><br />
.<br />
.<br />
.<br />
# Specify the proto tag to be used for routes olsr inserts into kernel<br />
# currently only implemented for linux<br />
# valid values under linux are 1 .. 254<br />
# 1 gets remapped by olsrd to 0 UNSPECIFIED (1 is reserved for ICMP redirects)<br />
# 2 KERNEL routes (not very wise to use)<br />
# 3 BOOT (should in fact not be used by routing daemons)<br />
# 4 STATIC<br />
# 8 .. 15 various routing daemons (gated, zebra, bird, & co)<br />
# (defaults to 0 which gets replaced by an OS-specific default value<br />
# under linux 3 (BOOT) (for backward compatibility)<br />
#<br />
RtProto 8<br />
#<br />
# Specifies the routing Table olsr uses<br />
# RtTable is for host routes, RtTableDefault for the route to the default<br />
# internet gateway (2 in case of IPv6+NIIT) and RtTableTunnel is for<br />
# routes to the ipip tunnels, valid values are 1 to 254<br />
# There is a special parameter "auto" (choose default below)<br />
# (with smartgw: default is 254/223/224)<br />
# (without smartgw: default is 254/254/254, linux main table)<br />
#<br />
RtTable 10<br />
RtTableDefault 10<br />
RtTableTunnel 10<br />
#<br />
# Specifies the policy rule priorities for the three routing tables and<br />
# a special rule for smartgateway routing (see README-Olsr-Extensions)<br />
# Priorities can only be set if three different routing tables are set.<br />
# if set the values must obey to condition<br />
# RtTablePriority < RtTableDefaultOlsrPriority<br />
# < RtTableTunnelPriority < RtTableDefaultPriority.<br />
# There are two special parameters, "auto" (choose fitting to SmartGW<br />
# mode) and "none" (do not set policy rule)<br />
# (with smartgw: default is none/32776/32776/32796)<br />
# (without smartgw: default is none/none/none/none)<br />
#<br />
# RtTablePriority auto<br />
# RtTableDefaultOlsrPriority auto<br />
# RtTableTunnelPriority auto<br />
# RtTableDefaultPriority auto<br />
</pre><br />
<br />
<br />
Das Freifunk Franken intere Routing kann nun getestet werden.<br />
<br />
Zunächst einmal starten wir olsr neu:<br />
<code><br />
/etc/init.d/olsrd restart<br />
</code><br />
<br />
<br />
Die Routinginformationen des olsr-meshes sollten in der fff-Routingtabelle auftauchen:<br />
<code><br />
ip route show table fff<br />
</code><br />
<br />
Exemplarischer Auszug:<br />
<pre><br />
.<br />
.<br />
.<br />
10.50.32.1 via 10.50.32.1 dev ro1 proto gated metric 2 onlink <br />
10.50.32.2 via 10.50.32.2 dev nue1 proto gated metric 2 onlink <br />
10.50.40.0/21 via 10.50.32.1 dev ro1 proto gated metric 2 onlink <br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Eine IP4 aus der Nürnberger Hood (10.50.40.0/21) sollte z.B. von Fürth aus (10.50.32.0/21) erreichbar sein:<br />
<br />
<code><br />
ping 10.50.40.3<br />
</code><br />
<br />
Antwort:<br />
<pre><br />
PING 10.50.40.3 (10.50.40.3) 56(84) bytes of data.<br />
64 bytes from 10.50.40.3: icmp_seq=1 ttl=63 time=42.2 ms<br />
64 bytes from 10.50.40.3: icmp_seq=2 ttl=63 time=42.7 ms<br />
^C<br />
--- 10.50.40.3 ping statistics ---<br />
2 packets transmitted, 2 received, 0% packet loss, time 1000ms<br />
rtt min/avg/max/mdev = 42.279/42.516/42.753/0.237 ms<br />
</pre><br />
<br><br />
=== OpenVPN Start/Stop Automatik ===<br />
OLSR testet mit dem Dynamic Gateway Plugin, ob die Default Route über den OpenVPN Tunnel noch funktioniert, indem regelmässig teilweise mehrere verschiedene Ziele über den Tunnel angepingt werden. Sollte der OpenVPN Tunnel nicht mehr funktionieren, baut OLSR eine neue Default-Route zu einem anderem Gateway auf, über das dann der Internet-Traffic läuft. Beide Default-Routen, die über den OpenVPN Tunnel und die von OLSR, existieren parallel, wobei zunächst weiterhin die OpenVPN Verbindung verwendet wird.<br />
<br />
Da die OpenVPN Verbindung ausgefallen ist, aber trotzdem noch als bevorzugte Default-Route eingetragen ist, ist die Internetanbindung bis die Störung VPN-Server seitig behoben ist, trotzdem nicht verfügbar. <br />
<br />
Für diesen Anwendungsfall wird ein Skript vorgeschlagen, dass die Funktion des OpenVPN Tunnels überwacht und den Tunnel (und die OpenVPN Default-Route) bei Nicht-Funktion abbaut. Um die Funktion zu überprüfen werden in regelmässigen Abständen 2 verschiedene Ziele über den Tunnel angepingt. Scheitert dies, wird der Tunnel für einen gewissen Zeitraum abgebaut, in dem dann stattdessen das OLSR Dynamic Gateway Plugin das Routing übernimmt. Danach wird die Verbindung wieder aufgebaut. Anschliessend wird überprüft, ob der OpenVPN-Tunnel wieder funktioniert. Tut er es nicht, wird er wieder abbgebaut, funktioniert er, bleibt er bis zur Detektion der nächsten Störung als Internetanbindung erhalten.<br />
<br />
Man importiert die Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/auto_start-stop_ovpn.sh -P /usr/local/bin/<br />
</code><br />
<br />
Alternativ kann man statt der Vorlage auch eine leere Datei anlegen:<br />
<code><br />
touch /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
Man macht das Skript ausführbar:<br />
<code><br />
chmod +x /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
<br />
Nun öffnet man die Datei im Editor ...<br />
<code><br />
vi /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
... und füllt sie mit Inhalt oder editiert den importierten Inhalt:<br />
<pre><br />
#!/bin/bash<br />
<br />
IF="tun0" # Interface used for ping<br />
ping1_target="8.8.8.8" # IP no. 1 used for ping<br />
ping2_target="82.165.229.31" # IP no. 2 used for ping<br />
ping_interval="5" # waiting time in-between two pings<br />
switchback_interval="3600" # waiting time for interface to recover before probing again<br />
start_grace="10" # waiting time to allow for tunnel restart<br />
logfile="/dev/null" # logfile for debug<br />
gwsel_lockfile="/tmp/gwsel_lockfile" # lockfile to allow for low bandwidth settings <br />
<br />
openvpn_stop-cmd () { # command used disabling tunnel<br />
service openvpn stop # ubuntu<br />
#/etc/init.d/openvpn stop # debian<br />
#killall openvpn # hardcore<br />
}<br />
<br />
openvpn_start-cmd () { # command used enabling tunnel<br />
service openvpn start # ubuntu<br />
#/etc/init.d/openvpn start # debian<br />
#openvpn /etc/openvpn/*.conf & # hardcore<br />
}<br />
<br />
ping1 () {<br />
echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF" &>> $logfile<br />
ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF &>> $logfile<br />
ping1_ExitCode=$?<br />
echo "$(date): Exit Status: ${ping1_ExitCode}" &>> $logfile<br />
}<br />
<br />
ping2 () {<br />
echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF" &>> $logfile<br />
ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF &>> $logfile<br />
ping2_ExitCode=$?<br />
echo "$(date): Exit Status: ${ping2_ExitCode}" &>> $logfile<br />
}<br />
<br />
<br />
while true<br />
do<br />
# wait for interface build-up, if interface not present<br />
if [ ! -h "/sys/class/net/$IF" ]; then<br />
echo "$(date): Interface $IF not detected. Waiting ${start_grace} seconds." &>> $logfile<br />
sleep ${start_grace}<br />
fi<br />
<br />
# perform ping<br />
ping1<br />
ping2<br />
<br />
# check if ping successful<br />
if ([[ ${ping1_ExitCode} -eq 0 ]] || [[ ${ping2_ExitCode} -eq 0 ]]); then<br />
sleep ${ping_interval}<br />
else<br />
logger -t "$0" ${ping1_target} and ${ping2_target} not reached via interface $IF.<br />
echo "$(date): ${ping1_target} and ${ping2_target} not reached via interface $IF." &>> $logfile<br />
touch ${gwsel_lockfile} &>> $logfile<br />
<br />
if [ -h "/sys/class/net/$IF" ]; then<br />
logger -t "$0" Stopping interface $IF.<br />
echo "$(date): Stopping interface $IF." &>> $logfile<br />
openvpn_stop-cmd &>> $logfile<br />
fi<br />
<br />
sleep ${switchback_interval}<br />
rm -f ${gwsel_lockfile} &>> $logfile<br />
<br />
if [ ! -h "/sys/class/net/$IF" ]; then<br />
logger -t "$0" Restoring interface $IF to probe for recovery.<br />
echo "$(date): Restoring interface $IF to probe for recovery." &>> $logfile<br />
openvpn_start-cmd &>> $logfile<br />
fi<br />
fi<br />
done<br />
</pre><br />
<br />
Hierbei können im Skript folgende Anpassungen vorgenommen werden:<br />
*openvpn_stop-cmd: Der Befehl, mit dem der OpenVPN Tunnel '''abgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ als Prozess gekillt werden.<br />
*openvpn_start-cmd: Der Befehl, mit dem der OpenVPN tunnel '''aufgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ per openvpn Kommandozeilenaufruf gestartet werden.<br />
*IF: Das OpenVPN Tunnel Device. Normalerweise ist das tun0.<br />
*ping1_target,ping2_target: Die IP-Adressen die über das Tunnel-Interface IF angepingt werden, um den Tunnel auf Funktion zu überprüfen. Vorauswahl: Google DNS und Web.de<br />
*ping_interval: Der zeitliche Anstand zwischen zwei Ping-Versuchen. Vorauswahl: 5 Sekunden.<br />
*switchback_interval: Der Zeitraum, den der Tunnel abgebaut bleibt, sollte er als nicht-funktionierend erkannt worden sein. Es wird ein träges Verhalten empfohlen. Vorauswahl: 3600 Sekunden.<br />
*start_grace: Der Zeitraum, der dem Tunnel zum Starten eingeräumt wird. Die Timer-Funktion macht ferner das Skript gegen Restarts des Tunnels unempfindlich.<br />
*logfile: Für Debug Zwecke kann man detaillierte Ausgaben hier in eine Datei umleiten.<br />
<br />
Das Skript selber kann manuell ...<br />
<code><br />
auto_start-stop_ovpn.sh &<br />
</code><br />
<br />
...und bei jedem Systemstart mit gestartet werden, indem es z.B. in /etc/rc.local ...<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
...wie folgt eingetragen wird:<br />
<pre><br />
.<br />
.<br />
.<br />
#enable tunnel monitoring with 60 seconds delay<br />
(sleep 60; auto_start-stop_ovpn.sh &) &<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Getestet werden kann das Skript z.B., indem man sich alle Default-Routen der fff-Tabelle anzeigen lässt: <br />
<code><br />
watch "ip route show table fff | grep default"<br />
</code><br />
<br />
und parallel dazu auf einer zweiten Shell das openvpn deaktiviert:<br />
<code><br />
killall openvpn<br />
</code><br />
<br />
Es sollte eine neue Default-Route zu einem anderen Gateway aufgebaut werden, über die der Internet-Traffic dann läuft. Die Route über den OpenVPN Tunnel sollte verschwinden. Nach der eingestellten Zeit wird der OpenVPN Tunnel durch das Skript wieder reaktiviert. Danach existieren beide Default-Routen parallel, bis OLSR seine Route automatisch wieder abbaut. Die OpenVPN Default-Route bleibt und ist wieder aktiv.<br />
<br><br />
<br />
=== Priorisieren von OLSR Routen ===<br />
OLSR erstellt die fff-Routingtabelle selbstständig, indem es die Linkqualität anhand von Algorithmen bewertet. Diese Bewertung ist recht volatil, was dazu führen kann, das die von OLSR ausgesuchte Default-Route häufig wechselt. Für die verbundenen Clients wechselt jedes mal die externe Internet IP mit, je nachdem über welches Gateway OLSR den Internet-Traffic gerade abwirft. Bei IP-Wechsel stoppen z.B. Downloads aus dem Internet, stoppen Videos im Abspielen, werden ssh Verbindungen gekappt.<br />
<br />
Um diese Dynamik nicht allzu schnell zu gestalten, empfiehlt es sich OLSR eine oder zwei Default-Routen mitzuteilen, die bevorzugt verwendet werden. Zusätzlich wird NatThreshold, einen Schwellwert den die neue Default-Route besser sein muss als die alte, bevor gewechselt wird, definiert.<br />
<br />
Dies geschieht über Gewichtungsfaktoren in olsrd.conf:<br />
<br />
<code><br />
vi /etc/olsrd/olsrd.conf<br />
</code><br />
<br />
Routen kann man im Abschnitt InterfaceDefaults priorisieren. <br />
Hier können Gewichtungsfaktoren für die GRE-Tunnel zu anderen Gateways eingeführt werden, mit denen die Link-Qualität beeinflusst werden kann:<br />
<pre><br />
.<br />
.<br />
.<br />
# If a certain route should be preferred<br />
# or ignored by the mesh, the Link Quality<br />
# value of a node can be multiplied with a factor<br />
# entered here. In the example the route<br />
# using 192.168.0.1 would rather be ignored.<br />
# A multiplier of 0.5 will result in a small<br />
# (bad) LinkQuality value and a high (bad)<br />
# ETX value.<br />
<br />
# preferred link<br />
LinkQualityMult <tunnel1_ip> 0.99<br />
<br />
# preferred link<br />
LinkQualityMult <tunnel2_ip> 0.99<br />
<br />
# This multiplier applies to all other nodes<br />
LinkQualityMult default 0.7<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Im Beispiel werden alle Routen herabgestuft (Faktor 0.7), mit der Ausnahme derer die über <tunnel1_ip> oder <tunnel2_ip> laufen (Faktor 0.99). <tunnel_ip1> sind dabei die Point-to-Point Partner IPs der GRE Tunnel der jeweiligen Gateways im Freifunk Netz. Die nicht herabgestuften Routen können analog als priorisiert betrachtet werden. Für eine Priorisierung der Route von nue1 zu ro1 wäre die <tunnel1/2_ip> z.B. die 10.50.252.1 (Vgl. [[Portal:Netz]]).<br />
<br />
NatThreshold wird im Hauptabschnitt von olsrd.conf definiert:<br />
<pre><br />
.<br />
.<br />
# If the NAT-Endpoint (the preferred 0/0 HNA emitting node)<br />
# is to be changed, the ETX value of the current 0/0 is<br />
# multiplied with the NatThreshold value before being<br />
# compared to the new one<br />
# The parameter can be a value between 0.1 and 1.0, but<br />
# should be close to 1.0 if changed.<br />
<br />
NatThreshold 0.7<br />
.<br />
.<br />
</pre><br />
<br />
Im Beispiel muss die Linkqualität der neuen Default-Route um 30% besser bewertet als die aktuelle sein, bevor die Default-Route gewechselt wird.<br />
<br />
Die Änderungen werden nach Neustart von OLSR aktiv:<br />
<code><br />
/etc/init.d/olsrd restart<br />
</code><br />
<br><br />
= Einbringen des Gateways in die Hood / Keyserver =<br />
Abschliessend muss das Gateway im Keyserver als Gateway der entsprechenden Hood eingetragen werden. Hierfür benötigt man einen Keyserver-Administrator => [[Server]].<br />
<br />
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.<br />
<br />
Der DHCP-Server sollte als letzter Schritt aktiviert werden (s.o.)<br />
<br><br />
= Transparent Proxy =<br />
Auf dem Gateway kann (aber muss nicht) ein Proxy-Server installiert werden, der Dateien (z.B. Bilder), die schon mal angefragt wurden, nicht aus dem Internet holt, sondern als "lokal" gespeicherte Datei direkt vom Gateway bereitstellt. Die Clients werden dabei über den Proxy gezwungen, d.h. das Gateway leitet die Anfragen pauschal an den Proxy weiter, welcher entscheidet ob der die Anfrage selber bedient oder Gateway-extern anfragt. <br />
<br />
Die Einrichtung eines Proxys ist '''optional''', d.h. der Proxy ist für die Funktion des Gateways nicht notwendig. Proxy-Server reduzieren Antwortzeiten und Traffic für sich '''häufig''' wiederholende Anfragen (z.B. Spiegel Online, Windows Update).<br />
<br />
'''Hinweis''': <br />
Die Einrichtung eines Proxy ist umstritten, da:<br />
* HTTP-Header, wenn auch in geringem Umfang, verändert werden<br />
* Daten, wenn auch nicht direkt einsehbar, auf dem Gateway gespeichert werden<br />
* Daten nicht unmittelbar von der Originalquelle bezogen werden <br />
* Die Effizienzsteigerung gering ist. Nach Auswertung werden ca. 7% aller unverschlüsselten HTTP-Anfragen von dem Gateway direkt beantwortet. Für diese 7% halbiert sich der benötigte Traffic, wobei ein Großteil aller Webseiten heutzutage verschlüsselt wird und z.Zt. 50% des benötigten Traffics Overhead ist. <br />
* Zusätzliche Ressourcen (RAM, Prozessor) auf dem Gateway benötigt werden <br />
<br />
'''Inkompatiblität''': Die Konfiguration funktioniert z.Zt. nicht im Zusammenspiel mit der "OpenVPN Start/Stop Automatik" und dem automatischen OLSR Re-Routing des Default-Gateways (Dynamic Gateway Plugin).<br />
<br><br />
== Installation ==<br />
Installiert wird der de-facto-Standard squid:<br />
<code><br />
apt-get install squid3<br />
</code><br />
<br />
Für die kommende Konfiguration stoppen wir squid wieder:<br />
<code><br />
/etc/init.d/squid3 stop<br />
</code><br />
<br><br />
== Konfiguration ==<br />
Die mit installiere Konfigurationsdatei squid.conf ist sehr umfangreich und bietet eine gute Dokumentationsbasis, ist damit aber auch etwas unhandlich.<br />
<br />
Aus diesem Grund empfiehlt es sich, die Datei umzubenennen:<br />
<code><br />
mv /etc/squid3/squid.conf /etc/squid3/squid.conf.orig<br />
</code><br />
<br />
Wir importieren die Datei von einer Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/squid.conf -P /etc/squid3/<br />
</code><br />
<br />
Alternativ können wir die Datei auch leer erstellen:<br />
<code><br />
touch /etc/squid3/squid.conf<br />
</code><br />
<br />
Danach öffnen wir die Konfigurationsdatei...<br />
<code><br />
vi /etc/squid3/squid.conf<br />
</code><br />
<br />
...und füllen diese mit Inhalt, der allerdings noch auf das Gateway angepasst werden muss:<br />
<pre> <br />
# cache size in MB / no. of subdirectories / no. of subsubdirectories<br />
cache_dir ufs /var/spool/squid3 100 16 256<br />
<br />
#maximum object size in cache (default: 4 MB)<br />
#maximum_object_size 128 MB<br />
maximum_object_size 4 MB<br />
<br />
# Memory used for caching<br />
cache_mem 32 MB<br />
<br />
# No access log<br />
#access_log /var/log/squid3/access.log combined<br />
access_log none<br />
<br />
# Hostname shown in messages<br />
visible_hostname fff<br />
<br />
# Bind Squid to port ... and configure as transparent proxy <br />
http_port 3128 intercept<br />
# In addition a forward proxy is required<br />
http_port 3129<br />
<br />
refresh_pattern ^ftp: 1440 20% 10080<br />
refresh_pattern ^gopher: 1440 0% 1440<br />
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0<br />
refresh_pattern . 0 20% 4320<br />
<br />
# Allow connects from Freifunk Franken network<br />
acl fff src 10.50.0.0/16 <br />
<br />
# DNS by Freifunk-IP of localhost and Google DNS<br />
dns_nameservers 10.50.32.5 8.8.8.8<br />
<br />
# Bind outgoing address to Freifunk-Server IP to allow for VPN Routing <br />
tcp_outgoing_address 10.50.32.5<br />
udp_outgoing_address 10.50.32.5<br />
<br />
# Privacy options <br />
via off<br />
forwarded_for delete<br />
<br />
# standard http anonymizer<br />
request_header_access From deny all<br />
#request_header_access Referer deny all<br />
#request_header_access User-Agent deny all<br />
<br />
## paranoid http anonymizer<br />
#request_header_access Authorization allow all<br />
#request_header_access Proxy-Authorization allow all<br />
#request_header_access Cache-Control allow all<br />
#request_header_access Content-Length allow all<br />
#request_header_access Content-Type allow all<br />
#request_header_access Date allow all<br />
#request_header_access Host allow all<br />
#request_header_access If-Modified-Since allow all<br />
#request_header_access Pragma allow all<br />
#request_header_access Accept allow all<br />
#request_header_access Accept-Charset allow all<br />
#request_header_access Accept-Encoding allow all<br />
#request_header_access Accept-Language allow all<br />
#request_header_access Connection allow all<br />
#request_header_access All deny all<br />
<br />
# Access controls<br />
acl SSL_ports port 443 # https<br />
acl Safe_ports port 80 # http<br />
acl Safe_ports port 21 # ftp<br />
acl Safe_ports port 443 # https<br />
acl Safe_ports port 70 # gopher<br />
acl Safe_ports port 210 # wais<br />
acl Safe_ports port 1025-65535 # unregistered ports<br />
acl Safe_ports port 280 # http-mgmt<br />
acl Safe_ports port 488 # gss-http<br />
acl Safe_ports port 591 # filemaker<br />
acl Safe_ports port 777 # multiling http<br />
<br />
acl CONNECT method CONNECT<br />
http_access deny !Safe_ports<br />
http_access deny CONNECT !SSL_ports<br />
http_access allow localhost manager<br />
http_access deny manager<br />
http_access allow fff<br />
http_access allow localhost<br />
http_access deny all<br />
</pre><br />
<br />
Hier '''müssen''' angepasst werden:<br />
* cache_dir: Die Gesamtgröße des Caches (hier: 100 MByte) muss so bemessen sein, dass auf der Partition auch bei Maximalgröße des Caches noch Speicher frei bleibt. Squid Standardeinstellung ist 100 MB bei 16 Verzeichnissen und jeweils 256 Unterverzeichnissen. Freier Speicherplatz kann mit "df -h" ermittelt werden.<br />
* dns_nameservers: Hier sollten die '''Freifunk-IPv4''' des Gateways (in diesem Beispiel 10.50.32.5) und eine externe IP (hier Google DNS 8.8.8.8) eingetragen werden. Wichtig ist, '''nicht localhost''' einzutragen, da die Anfrage im Zusammenspiel mit der "outgoing address" (s.u.) über die fff-Routingtabelle laufen muss.<br />
* tcp_outgoing_address und udp_outgoing_address: Diese beide Einträge sind elementar wichtig. Zwar funktioniert der Proxy auch ohne, routet aber nicht über das VPN sondern direkt vom Gateway ins Internet. Damit die fff-Routingtabelle verwendet wird, für die als Default-Gateway eine VPN Verbindung eingerichtet ist, tragen wir hier die Freifunk-IP des Gateways ein (10.50.<irgendwas>). In diesem Beispiel ist die Freifunk-IPv4 des Gateways die 10.50.32.5.<br />
* access_log: Das Access log sollte deaktiviert bleiben (access_log none), da es ein lebendiges Beispiel für Vorratsdatenspeicherung ist und die log-Dateien auch sehr schnell, sehr groß werden.<br />
<br />
Danach erstellen wir die Verzeichnisstruktur des Proxy:<br />
<code><br />
squid3 -z<br />
</code><br />
<br />
Jetzt sind wir fast fertig. Wir starten den Proxy:<br />
<code><br />
/etc/init.d/squid3 start<br />
</code><br />
<br />
Anfragen, die auf Port 80 (http) reinkommen, müssen nun noch auf Port 3128 umgeleitet werden. Auf Port 3128 lauscht unser Proxy, http-Anfragen werden quasi transparent (oder zwangsweise) über den Proxy geleitet :<br />
<code><br />
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
</code><br />
<br />
Damit unsere Portumleitung mit jedem Start von Squid eingerichtet und mit jedem Stopp aufgehoben wird, pflegen wir sie (nicht ganz sauber) im squid start/stop Skript mit ein:<br />
<code><br />
vi /etc/init.d/squid3<br />
</code><br />
<br />
und fügen '''zwei''' iptables Einträge nach dem Start und vor dem Stopp von Squid ein:<br />
<pre><br />
.<br />
.<br />
.<br />
start () {<br />
cache_dir=`find_cache_dir cache_dir`<br />
cache_type=`grepconf cache_dir`<br />
<br />
#<br />
# Create run dir (needed for several workers on SMP)<br />
#<br />
create_run_dir<br />
<br />
#<br />
# Create spool dirs if they don't exist.<br />
#<br />
if test -d "$cache_dir" -a ! -d "$cache_dir/00"<br />
then<br />
log_warning_msg "Creating $DESC cache structure"<br />
$DAEMON -z -f $CONFIG<br />
fi<br />
<br />
umask 027<br />
ulimit -n 65535<br />
cd $cache_dir<br />
start-stop-daemon --quiet --start \<br />
--pidfile $PIDFILE \<br />
--exec $DAEMON -- $SQUID_ARGS < /dev/null<br />
# Use as transparent proxy<br />
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
return $?<br />
}<br />
<br />
stop () {<br />
PID=`cat $PIDFILE 2>/dev/null`<br />
# Use as transparent proxy<br />
iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
start-stop-daemon --stop --quiet --pidfile $PIDFILE --exec $DAEMON <br />
#<br />
# Now we have to wait until squid has _really_ stopped.<br />
#<br />
.<br />
.<br />
.<br />
</pre></div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Freifunk-Gateway_aufsetzen&diff=5357
Freifunk-Gateway aufsetzen
2016-01-23T13:01:58Z
<p>Green: /* B.A.T.M.A.N Gateway Selection */</p>
<hr />
<div>__TOC__<br />
[[Kategorie:Technik]]<br />
<br />
= Preface =<br />
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").<br />
<br />
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.<br />
<br />
Für Rat und Tat empfiehlt sich die Freifunk Franken Development Mailingliste.<br />
<br><br />
= Vorraussetzungen =<br />
* ssh-Zugang zum Server<br />
* Root Zugriff auf den Server. Entweder man ist "root" (Annahme in diesem Artikel) oder man kann Befehle mit "root-Rechten" durch ein vorgesetztes "sudo" ausführen sowie die Möglichkeit auf dem Server Kernelmodule zu laden (kann nicht jeder VServer!) <br />
* Grundlegende Netzwerkkenntnisse<br />
** IPv4 und Netzmaske<br />
** Devices<br />
** Routing (Default Route, Interfaces, Routing-Table) <br />
* Kentnisse <br />
** im Umgang mit Texteditoren (der im Artikel verwendete Editor kann durch beliebig andere ersetzt werden, z.B. durch "nano")<br />
** im Umgang mit der Linux Shell (z.B. Kommandozeilenparameter, Shell-Scripte, Umleitungen)<br />
** in der (selbständigen Nach-)Installation von (fehlenden) Software-Paketen<br />
** im Kompilieren von Software-Quellen<br />
<br><br />
= Referenzen / Andere Freifunk HowTo's =<br />
* http://wiki.freifunk.net/Freifunk_Hamburg/Gateway <br />
* http://wiki.mag.lab.sh/wiki/Freifunk_Fulda/Gateway<br />
<br><br />
= Anforderungen an Gateways =<br />
Die Anforderungen an das Gateway sind an sich niedrig. Wichtig ist, dass die Möglichkeit besteht, eigene Kernel-Module zu laden und das monatliche Traffic-Kontingent nicht zu niedrig ist. Entsprechend sind OpenVZ, Linux-vServer und ähnliche Containerlösungen nicht geeignet.<br />
<br />
Hardware:<br />
* CPU: 1x (64Bit)<br />
* RAM: 256MB .. 1GB<br />
* HDD: > 5 GB<br />
* NIC: 1x<br />
<br />
Software:<br />
* Debian Jessie (8) 64Bit Kernel <br />
* fastd v17<br />
* openvpn<br />
* B.A.T.M.A.N. adv 2013.4.0<br />
* dhcpd<br />
* olsr<br />
* bind9<br />
<br />
Pauschal gibt es keine Mindestanforderungen für den Trafficverbrauch. Es kommt sehr darauf an, wo der Server eingesetzt wird. <br />
'''Momentan suchen wir aber vor allem Server mit einem kostenlosen Traffic von mindestens 10-20 TB/Monat.'''<br />
<br><br />
== Anonymisierung (Störerhaftung) ==<br />
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.<br />
<br />
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. <br />
<br />
Folgende VPN-Anbieter sind zu diesem Zeitpunkt jedoch empfehlenswert:<br />
<br />
* [https://mullvad.net/en/ Mullvad] (Schweden, Niederlande)<br />
** Bis zu drei gleichzeitige Verbindungen<br />
** Kann man anonym mit Bitcoin bezahlen<br />
** Serverauswahl über die ausgelieferte OpenVPN-Konfiguration<br />
*** Server in den Niederlanden sind abends oft stark ausgelastet<br />
**(Gute Erfahrungen in Lübeck)<br />
<br />
* [https://integrityvpn.com/ Integrity VPN] (Schweden, Port80)<br />
** 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.<br />
**Hat eine überaus seriöse Webseite und eine Ltd. erfunden.™<br />
**Hat schon mal was von IPv6 gehört. Nutzt es zurzeit jedoch nur für SEO.<br />
**Blockiert Port 25 derzeit nicht.<br />
**Ist ein ein neuer Anbieter, der _bisher_ unausgelastet wirkt.<br />
** sind derzeit noch nicht nicht overselled und haben ihren Krams scheinbar halbwegs sauber konfiguriert<br />
<br />
* [https://ipredator.se/ Ipredator] (Schweden, Niederlande, Deutschland)<br />
** (Glänzen nicht durch Kompetenz, da sie lange Zeit nur PPTP angeboten haben)<br />
** Mögen schnelle Reconnects nicht -> manchmal muss man OpenVPN ein paar Stunden deaktivieren, bevor es wieder funktioniert.<br />
** Möchten bald auch IPv6 anbieten.<br />
** Angeblich Reseller von relakks<br />
<br />
Ungetestet:<br />
* [https://www.anonine.com/en Anonine VPN] (Portlane)<br />
* [https://privacy.io/ privacy.io] (Portlane)<br />
* [http://prq.se/?p=tunnel&intl=1 prq.se] (Eigenes Netz, teuer)<br />
* [http://arethusa.su/vpn.html Arethusa VPN] (Loggen in Frankreich, andere Server angeblich nicht)<br />
<br />
Einige Freifunknetze mieten auch VMs in Osteuropa. Da die VMs noch nicht an ihre Grezen stößt könnte man diese auch mitnutzen. Ansprechpartner wäre s0ma.<br />
<br><br />
== Anbindung an andere Netze ==<br />
Es gibt drei relativ relevante Netzwerke bei denen es sich lohnt, das lokale Netz damit zu verbinden:<br />
<br />
* InterCity-VPN zwischen den meisten Freifunknetzen<br />
** BGP<br />
** kleine Übsicht der http://www.ddmesh.de/topology/ic-vpn-verbindungen.html<br />
** Mehr Infos http://wiki.freifunk.net/IC-VPN<br />
<br />
* DN42<br />
** BGP<br />
** Experimentelles Darknet zur Erprobung von Routing-Technologien und so weiter, wird privat betrieben. Viel interessantes Zeugs™<br />
** 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.<br />
<br />
* ChaosVPN<br />
** Tinc<br />
** Relativ großes „Darknet“ zwischen vielen Hackerspaces auf der ganzen Welt.<br />
<br><br />
== vServer-Anbieter die empfehlenswert sind ==<br />
* [https://www.de-punkt.de/vserver.html de-punkt] (Databurg, FFM)<br />
** Schneller Speicher, gut bezahlbar, KVM, nur Traffic-Flat™® das übliche.<br />
* [http://www.hetzner.de/hosting/produktmatrix_vserver/vserver-produktmatrix Hetzner] (Falkenstein)<br />
** Bezahlbar, 6.90€/TB Extratraffic, KVM<br />
** Achtung: Die Netzwerkarte der VM ist aus Kompatibilitätsgründen auf e1000 gesetzt. Diese "Netzwerkkarte" kommt nicht mit den vielen UDP-Paketen von fastd zurecht. Deshalb muss man vor Verwendung als Gateway die Netzwerkkarte auf "virtio" stellen.<br />
* [http://colorhost.de/server/vserver/ colorhost] (über 23media, Global Switch, FFM)<br />
* Untersagt Nutzung für Freifunk (http://colorhost.de/server/vserver/kvm/small/)<br />
** Achtung: Nur Xen oder Xen HVM funktionieren<br />
* [http://www.xirra.net/en/v-server/productmatrix/ xirra] (Core-Backbone, NBG)<br />
** KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.<br />
* [http://buyvm.net/ BuyVM]<br />
** 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.<br />
* [http://webhod.de webhod]<br />
** 9,99 € für die kleinste KVM im Monat[https://www.webhod.de/de/vserver/kvm.html]<br />
<br><br />
== Server-Anbieter die '''nicht''' empfehlenswert sind ==<br />
* [http://www.wrzhost.com/ WRZhost]<br />
** 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.<br />
<br />
* [https://www.netcup.de/ netcup]<br />
** V-Server laufen zwar grundsätzlich gut, allerdings halten sie sich nicht an ihre Versprechungen. Server wurde bereits mehrfach gedrosselt obwohl der Traffic weit unter den versprochenen 80 Mbit/s war (zwischen 30 und 40 Mbit/s). Die Drosselung tritt ohne Vorwarnung in Kraft und man kann seinen Server nicht mehr erreichen. Entdrosselung nur auf Nachfrage und dann auch nur mit einigem hin und her.<br />
<br><br />
= Grundinstallation des Servers =<br />
Vom ausgesuchten Hoster lassen wir uns eine aktuelle Linux-Distribution installieren oder ausliefern, wobei sich die Anleitung auf ein Debian 8 / Jessie bezieht.<br />
<br><br />
== Repositories und Update ==<br />
Als erstes werfen wir einen Blick in...<br />
<br />
<code><br />
vi /etc/apt/sources.list<br />
</code><br />
<br />
...und schauen, inwieweit auf die gleichen Software-Repositories verwiesen wird:<br />
<br />
<pre> <br />
deb http://security.debian.org/ jessie/updates main<br />
deb-src http://security.debian.org/ jessie/updates main<br />
<br />
deb http://ftp.de.debian.org/debian/ jessie main contrib non-free<br />
deb-src http://ftp.de.debian.org/debian/ jessie main contrib non-free<br />
<br />
deb http://ftp.de.debian.org/debian/ jessie-updates main<br />
deb-src http://ftp.de.debian.org/debian/ jessie-updates main<br />
<br />
</pre><br />
<br />
Danach bringen wir das System auf einen aktuellen Stand:<br />
<br />
<code><br />
apt-get update<br />
<br />
apt-get upgrade<br />
</code><br />
<br><br />
== Sicherheit ==<br />
Den SSH-Zugang besser schützen durch:<br />
* Änderung des Ports<br />
* login nur mit key<br />
* Siehe [http://www.thomas-krenn.com/de/wiki/Absicherung_eines_Debian_Servers hier] für genaue Anleitung: <br />
<br />
<code><br />
apt-get install fail2ban<br />
</code><br />
<br />
und [http://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban_absichern einrichten]<br />
<br />
So,nun sollte der Server ausreichend abgesichert sein.<br />
<br><br />
== B.A.T.M.A.N. adv 2013.4.0 Kernel-Modul ==<br />
Batman-Adv aus Jessie ist zu neu. Hier muss manuell das alte B.A.T.M.A.N. advanced 2013.4.0 gebaut werden.<br />
<br />
Hierfür benötigen wir minimal die Paketquellen build-essential, linux-headers-amd64 und git:<br />
<br />
<code><br />
apt-get install build-essential linux-headers-amd64 git gnupg-curl<br />
</code><br />
<br />
Die Softwarequellen müssen heruntergeladen...<br />
<code><br />
cd ~<br />
<br />
git clone https://github.com/freifunk-gluon/batman-adv-legacy<br />
<br />
cd batman-adv-legacy<br />
</code><br />
<br />
... und kompiliert und installiert werden:<br />
<br />
<code><br />
make<br />
<br />
make install<br />
</code><br />
<br />
Hinweis: Sollten noch Paketquellen fehlen, wird dies während des Kompilierens gemeldet. Die Software-Quellen müssen nachinstalliert werden und der letzte Kompilierungs- und Installationsschritt so lange wiederholt werden, bis die Software erfolgreich erstellt wurde.<br />
<br />
Nach erfolgreicher Erstellung kann das B.A.T.M.A.N Kernel Modul per modprobe händisch eingebunden werden:<br />
<br />
<code><br />
modprobe batman-adv<br />
</code><br />
<br />
Es sollte dann im Kernel-log ....<br />
<code><br />
dmesg | grep batman_adv<br />
</code><br />
<br />
... mit einem Eintrag gelistet werden:<br />
<pre><br />
batman_adv: B.A.T.M.A.N. advanced 2013.4.0-21-ga854277-dirty (compatibility version 14) loaded<br />
</pre><br />
<br />
Das Kernelmodul von B.A.T.M.A.N. kann dann bei jedem Neustart des Systems geladen werden, indem in die Datei /etc/modules:<br />
<br />
<code><br />
vi /etc/modules<br />
</code><br />
<br />
..der Eintrag "batman-adv" hinzugefügt wird:<br />
<br />
<pre><br />
batman-adv<br />
</pre><br />
<br><br />
== B.A.T.M.A.N adv 2013.4.0 batctl ==<br />
Gleiches gilt für batctl, ein Kommandozeilenprogramm zur B.A.T.M.A.N Konfiguration. Die alte Version 2013.4.0 muss selber gebaut werden, da die Debian 8 / Jessie Paketquellen zu neu sind.<br />
<br />
Herunterladen und Entpacken der Softwarequellen:<br />
<code><br />
cd ~<br />
<br />
wget http://downloads.open-mesh.org/batman/releases/batman-adv-2013.4.0/batctl-2013.4.0.tar.gz<br />
<br />
tar xzf batctl-2013.4.0.tar.gz<br />
<br />
cd batctl-2013.4.0<br />
</code><br />
<br />
Kompilieren und Installieren:<br />
<br />
<code><br />
make<br />
<br />
make install<br />
</code><br />
<br />
Hinweis: Auch hier müssen ggf. fehlende Quellen händisch nachinstalliert und das Kompilieren und Installieren bis zum Erfolg wiederholt werden.<br />
<br><br />
== FastD ==<br />
Die Verbindung zwischen Gateway und Router wird über einen fastd-Tunnel realisiert.<br />
<br />
Hierfür müssen wir ein neues Repository in der Datei /etc/apt/sources.list deklarieren:<br />
<br />
<code><br />
vi /etc/apt/sources.list.d/universe-factory.list<br />
</code><br />
<br />
Dort fügen wir folgendes Repository an:<br />
<br />
<pre><br />
deb http://repo.universe-factory.net/debian/ sid main<br />
deb-src http://repo.universe-factory.net/debian/ sid main<br />
</pre><br />
<br />
Danach die PGP Schlüssel holen:<br />
<code><br />
gpg --keyserver hkps://hkps.pool.sks-keyservers.net --recv-key 16EF3F64CB201D9C<br />
<br />
gpg -a --export 16EF3F64CB201D9C | apt-key add -<br />
</code><br />
<br />
Datenbankupdate der Paketverwaltung:<br />
<code><br />
apt-get update<br />
</code><br />
<br />
Installation von fastd: <br />
<code><br />
apt-get install fastd <br />
</code><br />
<br><br />
<br />
== OpenVPN ==<br />
OpenVPN (falls benötigt) installieren wir mit:<br />
<code><br />
apt-get install openvpn<br />
</code><br />
<br><br />
== DHCP ==<br />
Den DHCP Server installieren wir mit:<br />
<code><br />
apt-get install isc-dhcp-server <br />
</code><br />
<br><br />
== Bind9 ==<br />
Als DNS Server nehmen wir hier den de-facto-Standard bind:<br />
<code><br />
apt-get install bind9 <br />
</code><br />
<br><br />
== OLSR ==<br />
Als Routing-Protokoll, um die einzelnen Hoods später zu einem Freifunk-Franken weit kommunizierenden Netz zu verbinden, wird OLSR installiert:<br />
<br />
<code><br />
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd_0.6.8.1-1_amd64.deb<br />
<br />
dpkg -i olsrd_0.6.8.1-1_amd64.deb<br />
<br />
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd-plugins_0.6.8.1-1_amd64.deb<br />
<br />
dpkg -i olsrd-plugins_0.6.8.1-1_amd64.deb<br />
<br />
</code><br />
<br><br />
= Konfigurieren des Freifunk-Gateways =<br />
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 />
<br><br />
== IPv4 des Gateways, IP-Bereich der Hood und DHCP Range des Gateway==<br />
Für das Gateway suchen wir uns unter [[Portal:Netz]] eine IPv4 Adresse aus dem statischen Range der Hood aus. Für Fürth läuft der Bereich für die statischen Adressen z.B. von 10.50.32.1 - 10.50.32.255. Hiervon suchen wir uns eine '''freie''' Adresse aus, und reservieren diese, indem wir sie weiter unten in die Tabelle der statischen IPs eintragen.<br />
<br />
Die Fürther Hood hat den IP-Bereich 10.50.32.0-10.50.32.255. Als Netzwerk wird dieser Bereich mit 10.50.32.0/21 deklariert, d.h. die ersten 21 Bit der IP identifizieren das Netzwerk "Fürther Hood" und die restlichen 11 Bit stehen zur IP Vergabe zur Verfügung, wobei Anfang (10.50.32.0) und Ende des Bereiches (10.50.39.255) reserviert sind und nicht, weder statisch noch dynamisch durch DHCP, belegt werden dürfen. Eine alternative Schreibweise zu 10.50.32.0/21 ist das Double "Network 10.50.32.0" und "Netmask 255.255.248.0". Ein entsprechender IP-Rechner zur analogen Anwendung in anderen Hoods findet sich z.B. [http://www.heise.de/netze/tools/netzwerkrechner/ hier].<br />
<br />
Ebenso sollte man einen DHCP-Bereich innerhalb des IP-Bereichs der jeweiligen Hood, die der GW bedienen soll, reservieren (d.h. in die oberer Tabelle unter [[Portal:Netz]] eintragen). Jeder DHCP-Server vergibt dynamisch IPv4 Adressen an Clients aus einem vorher definierten Adressbereich. Dieser Adressbereich sollte sich:<br />
* innerhalb des IP-Range der Hood bewegen<br />
* sich nicht mit dem Adressbereich überschneiden, den andere DHCP Server in der Hood verwalten<br />
* sich nicht mit dem Bereich der statischen Adressen der Hood überschneiden<br />
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. Vom gesamten IP-Bereich der Fürther Hood vergibt z.B. das Gateway fff-nue1 die Teilmenge 10.50.35.0 - 10.50.36.255 an Clients und teilt ihnen auf dem Weg auch gleich mit, wie sie Domain-Namen in IPs auflösen und auf welchem Weg sie ins Internet oder in andere Hoods kommen.<br />
<br><br />
== Routing Tabelle für Freifunk ==<br />
Fürs Routing im Freifunk Franken Netz wird eine eigene Routing Tabelle namens "fff" deklariert.<br />
<br />
Dies geschieht indem man in der Datei /etc/iproute2/rt_tables ...<br />
<code><br />
vi /etc/iproute2/rt_tables<br />
</code><br />
<br />
... folgendes am Ende einfügt:<br />
<br />
<pre><br />
10 fff<br />
</pre><br />
<br />
Unsere Freifunk Routing Tabelle lässt sich später durch<br />
<code><br />
ip route show table fff<br />
</code><br />
anzeigen, sobald wir die Tabelle mit Einträgen füllen.<br />
<br><br />
== B.A.T.M.A.N Netzwerk-Interface, fff Routingregeln und -tabelle ==<br />
'''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.<br />
<br />
In der Datei /etc/network/interfaces ...<br />
<br />
<code><br />
vi /etc/network/interfaces<br />
</code><br />
<br />
fügen wir zunächst folgenden Textblock des Gateways "klee" aus der Fürther Hood an:<br />
<br />
<pre><br />
.<br />
.<br />
.<br />
# device: bat0<br />
iface bat0 inet manual<br />
post-up ifconfig $IFACE up<br />
##Einschalten post-up:<br />
# IP des Gateways am B.A.T.M.A.N interface:<br />
post-up ip addr add 10.50.32.5/21 dev $IFACE<br />
# Regeln, wann die fff Routing-Tabelle benutzt werden soll: <br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.0.0.0/8 table fff <br />
post-up ip rule add to 10.0.0.0/8 table fff<br />
# Route in die Fuerther Hood: <br />
post-up ip route add 10.50.32.0/21 dev $IFACE table fff<br />
# Start des DHCP Servers:<br />
post-up invoke-rc.d isc-dhcp-server restart<br />
<br />
##Ausschalten post-down:<br />
# Loeschen von oben definieren Routen, Regeln und Interface: <br />
post-down ip route del 10.50.32.0/21 dev $IFACE table fff<br />
post-down ip rule del from 10.0.0.0/8 table fff<br />
post-down ip rule del to 10.0.0.0/8 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ifconfig $IFACE down<br />
<br />
# VPN Verbindung in die Fuerther Hood<br />
iface ffffuerthVPN inet manual<br />
post-up batctl -m bat0 if add $IFACE<br />
post-up ifconfig $IFACE up<br />
post-up ifup bat0<br />
post-down ifdown bat0<br />
post-down ifconfig $IFACE down<br />
</pre><br />
<br />
In diesem Beispiel sind:<br />
* IP des Gateway/Netzmaske der Fürther Hood: 10.50.32.5/21<br />
* IP des Netzwerks Fürther Hood / Netzmaske der Fürther Hood: 10.50.32.0/21.<br />
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.<br />
<br />
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.).<br />
<br />
Die Regeln definieren, das Traffic der<br />
* aus dem Netzwerk 10.0.0.0/8 kommt<br />
* das Netzwerk 10.0.0.0/8 zum Ziel hat<br />
* oder über die B.A.T.M.A.N Schnittstelle übermittelt wird<br />
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.<br />
<br />
Im post-down Abschnitt werden die vorher definierten Regeln, Interfaces und Routen wieder gelöscht.<br />
<br />
Der untere Abschnitt definiert einen VPN Tunnel in die Fürther Hood. Der Name des Interfaces im Beispiel (ffffuerthVPN) kann individuell neu vergeben werden.<br />
<br><br />
== FastD Start- und Verwaltungsscript ==<br />
Für die Konfiguration von fastd importieren wir eine Datei in ''/etc/fastd'' mit dem Befehl:<br />
<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/fff_beispiel_fastd.sh -P /etc/fastd/<br />
</code><br />
<br />
Alternativ kann das Skript aus einer leeren Datei erstellt werden:<br />
<code><br />
touch /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
danach öffnen wir diese:<br />
<br />
<code><br />
vi /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
und editieren das Skript oder fügen ein Neues ein:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
SERVERNAME="beispiel"<br />
<br />
hood="hoodeintragen"<br />
project="fff"<br />
port=10004<br />
<br />
SERVERNAME="$SERVERNAME.$hood"<br />
<br />
hostname=$SERVERNAME<br />
<br />
if [ ! -d /etc/fastd ]<br />
then<br />
mkdir /etc/fastd<br />
fi<br />
<br />
if [ ! -d /etc/fastd/$project.$hood ]<br />
then<br />
mkdir /etc/fastd/$project.$hood<br />
mkdir /etc/fastd/$project.$hood/peers<br />
<br />
#fastd config<br />
(<br />
echo "# Log warnings and errors to stderr"<br />
echo "log level error;"<br />
echo "# Log everything to a log file"<br />
echo "log to syslog as \"${project}${hood}\" level info;"<br />
echo "# Set the interface name"<br />
echo "interface \"${project}${hood}VPN\";"<br />
echo "# Support xsalsa20 and aes128 encryption methods, prefer xsalsa20"<br />
echo "#method \"xsalsa20-poly1305\";"<br />
echo "#method \"aes128-gcm\";"<br />
echo "method \"null\";"<br />
echo "# Bind to a fixed port, IPv4 only"<br />
echo "bind any:${port};"<br />
echo "# Secret key generated by \"fastd --generate-key\""<br />
echo "secret \"$(fastd --generate-key | grep -i Secret | awk '{print $2}')\";" <br />
echo "# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)" <br />
echo "# (see MTU selection documentation)" <br />
echo "mtu 1426;" <br />
echo "on up \"/etc/fastd/${project}.${hood}/up.sh\";" <br />
echo "on post-down \"/etc/fastd/${project}.${hood}/down.sh\";" <br />
echo "# Include peers from the directory 'peers'" <br />
echo "include peers from \"/etc/fastd/${project}.${hood}/peers\";" <br />
echo "secure handshakes no;"<br />
) >> "/etc/fastd/$project.$hood/$project.$hood.conf"<br />
<br />
#fastd-up<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifdown \$INTERFACE"<br />
) >> /etc/fastd/$project.$hood/down.sh<br />
<br />
chmod +x /etc/fastd/$project.$hood/down.sh<br />
<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifup \$INTERFACE" >> /etc/fastd/$project.$hood/up.sh<br />
) >> /etc/fastd/$project.$hood/up.sh<br />
chmod +x /etc/fastd/$project.$hood/up.sh<br />
fi<br />
<br />
pubkey=$(fastd -c /etc/fastd/$project.$hood/$project.$hood.conf --show-key --machine-readable)<br />
port=$(grep ^bind /etc/fastd/$project.$hood/$project.$hood.conf | cut -d: -f2 | cut -d\; -f1)<br />
<br />
# fire up<br />
if [ "$(/sbin/ifconfig -a | grep -i ethernet | grep ${project}${hood}VPN)" = "" ]<br />
then<br />
/bin/rm /var/run/fastd.$project.$hood.pid<br />
fastd -c /etc/fastd/$project.$hood/$project.$hood.conf -d --pid-file /var/run/fastd.$project.$hood.pid<br />
fi<br />
<br />
# register<br />
wget -T15 -q "http://keyserver.freifunk-franken.de/${project}/?name=$hostname&port=$port&key=$pubkey" -O /tmp/fastd_${project}.${hood}_output <br />
if [ "$?" != "0" ]<br />
then<br />
echo "Update failed"<br />
echo "Exiting, no clean up, no refresh"<br />
exit<br />
fi<br />
<br />
touch /tmp/fastd_${project}.${hood}_starting<br />
<br />
filenames=$(cat /tmp/fastd_${project}.${hood}_output| grep ^#### | sed -e 's/^####//' | sed -e 's/.conf//g')<br />
for file in $filenames<br />
do<br />
grep -A100 ^####$file.conf$ /tmp/fastd_${project}.${hood}_output | grep -v ^####$file.conf$ | grep -m1 ^### -B100 | grep -v ^### | sed 's/ float;/;/g' > "/etc/fastd/$project.$hood/peers/$file"<br />
echo 'float yes;' >> "/etc/fastd/$project.$hood/peers/$file"<br />
done<br />
<br />
#find old peers<br />
OLD=$(find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print)<br />
<br />
if [ -n "${OLD}" ] ; then<br />
echo "Lösche alte:"<br />
echo $OLD<br />
<br />
find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print | xargs /bin/rm /tmp/fastd_${project}.${hood}_starting<br />
fi<br />
<br />
#reload<br />
kill -HUP "$(cat /var/run/fastd.$project.$hood.pid)"<br />
<br />
exit 0<br />
</pre><br />
<br />
Zum Schluss geben wir noch ein<br />
<br />
<code><br />
chmod +x /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
ein, um das Skript ausführbar zu machen.<br />
<br />
Das Skript konfiguriert fastd, indem es<br />
* einen Schlüssel generiert, sollte keiner existieren<br />
* diesen Schlüssel mit dem Keyserver austauscht<br />
* die fastd Konfigurationsdatei anlegt<br />
* den fastd Dämonen startet<br />
<br />
Lediglich der Servername und die Hood müssen oben im Skript händisch angepasst werden. Der Dateiname des Skripts kann individuell angepasst werden.<br />
<br />
Nachdem das Script ausgeführt wurde, sollte man überprüfen ob das Interface in der Konfigurationsdatei unter /etc/fastd/fff.<Hoodname>/fff.<Hoodname>.conf das gleiche ist wie vorher in /etc/network/interfaces festgelegt. Wenn der Name nicht identisch ist (Groß-/Kleinschreibung), werden die Interfaces nicht starten.<br />
<br />
Hinweis: Das Gateway wird standardmässig in die Default-Hood eingebunden. Es wird hier lediglich ein Name für die Konfigurationsdatei und der Gateway Name definiert. Die Zuordnung des Gateways zu der Hood erfolgt später über den KeyXchange (siehe unten).<br />
<br><br />
== IP-Forwarding ==<br />
Um Anfragen, die das Gateway erreichen, weiterzuleiten, muss IP-Forwarding aktiviert werden. <br />
<br />
Manuell geht dies über:<br />
<code><br />
echo "1" > /proc/sys/net/ipv4/ip_forward<br />
<br />
echo "1" > /proc/sys/net/ipv6/conf/default/forwarding<br />
<br />
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding<br />
</code><br />
<br />
Dauerhaft lässt sich IP-Forwarding in /etc/sysctl.conf aktivieren:<br />
<code><br />
vi /etc/sysctl.conf<br />
</code><br />
<br />
.. um dort die Abschnitte einzukommentieren, die das Forwarding steuern:<br />
<pre><br />
.<br />
.<br />
.<br />
# Uncomment the next line to enable packet forwarding for IPv4<br />
net.ipv4.ip_forward=1<br />
<br />
# Uncomment the next line to enable packet forwarding for IPv6<br />
# Enabling this option disables Stateless Address Autoconfiguration<br />
# based on Router Advertisements for this host<br />
net.ipv6.conf.all.forwarding=1<br />
.<br />
.<br />
.<br />
</pre><br />
<br><br />
== Testen von B.A.T.M.A.N, fastd und Autostart ==<br />
Hierfür booten wir das Gateway am besten erst mal neu:<br />
<code><br />
reboot & exit<br />
</code><br />
<br />
und starten das fast.d Startskript manuell: <br />
<code><br />
/etc/fastd/fff_beispiel_fastd.sh &<br />
</code><br />
<br />
Beim Erststart werden Schlüsselpaare generiert und ausgetauscht, es kann also etwas dauern.<br />
<br />
Danach sollte der Aufruf von...<br />
<code><br />
pgrep fastd<br />
</code><br />
... mit der Prozess-ID beantwortet werden: Fastd läuft in dem Fall.<br />
<br />
<br />
Ein Aufruf von ifconfig:<br />
<code><br />
ifconfig<br />
</code><br />
<br />
sollte die neu erstellten Interfaces bat0 und ffffuerthVPN zurückliefern.<br />
Exemplarisch und als Auszug:<br />
<pre><br />
bat0 Link encap:Ethernet HWaddr ea:95:50:07:f7:27 <br />
inet addr:10.50.32.5 Bcast:0.0.0.0 Mask:255.255.248.0<br />
inet6 addr: fe80::e895:50ff:fe07:f727/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:1089992 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:849698 errors:0 dropped:1728 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0 <br />
RX bytes:141311612 (134.7 MiB) TX bytes:1052934594 (1004.1 MiB)<br />
<br />
.<br />
.<br />
.<br />
ffffuerthVPN Link encap:Ethernet HWaddr e6:3b:f3:b7:fc:db <br />
inet6 addr: fe80::e43b:f3ff:feb7:fcdb/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1426 Metric:1<br />
RX packets:32389694 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:2699525 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:500 <br />
RX bytes:4193328694 (3.9 GiB) TX bytes:1384843740 (1.2 GiB)<br />
.<br />
.<br />
.<br />
</pre><br />
Aus dem ifconfig Auszug für bat0 sollte die eingerichtete IP des Gateways und die Netzmaske hervorgehen.<br />
<br />
<br />
Die Abfrage der IP-Regeln:<br />
<code><br />
ip rule<br />
</code><br />
<br />
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):<br />
<pre><br />
32757: from all to 10.0.0.0/8 lookup fff <br />
32758: from 10.0.0.0/8 lookup fff <br />
32759: from all iif bat0 lookup fff <br />
</pre><br />
<br />
Eine Abfrage der fff-Routing Tabelle<br />
<code><br />
ip route show table fff <br />
</code><br />
<br />
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:<br />
<pre><br />
10.50.32.0/21 dev bat0 scope link<br />
</pre><br />
<br />
Ein Aufruf von "batctl o"<br />
<code><br />
batctl o <br />
</code><br />
<br />
ergibt eine Liste der MAC-Adressen von unseren nächsten Nachbarn. Exemplarisch und als Auszug:<br />
<pre><br />
[B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: ffffuerthVPN/e6:3b:f3:b7:fc:db (bat0)]<br />
Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ...<br />
96:43:c4:2e:73:68 0.004s (255) 96:43:c4:2e:73:68 [ffffuerthVPN]: 96:43:c4:2e:73:68 (255)<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
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:<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
Hier spendieren wir einen Eintrag, der fastd mit 10 Sekunden Verzögerung bei jedem Systemstart mitstartet:<br />
<pre><br />
# launch fastd with 10 seconds delay<br />
(sleep 10; sh /etc/fastd/fff_beispiel_fastd.sh) &<br />
</pre><br />
<br />
'''Zusätzlich''' muss ein Cronjob angelegt werden, der das Skript z.B. alle 10 Minuten ausführt:<br />
<code><br />
crontab -e<br />
</code><br />
<br />
Nun folgendes eingeben:<br />
<pre><br />
*/10 * * * * sh /etc/fastd/fff_beispiel_fastd.sh<br />
</pre><br />
<br />
und<br />
<br />
<code><br />
/etc/init.d/cron restart<br />
</code><br />
<br><br />
== OpenVPN-Tunnel einrichten ==<br />
Die Einrichtung eines OpenVPN Tunnels kann von Anbieter zu Anbieter variieren. <br />
Im Laufe der Zeit sollte die Dokumentation so um funktionierende Konfigurationen verschiedener Anbieter erweitert werden.<br />
<br><br />
=== Mullvad ===<br />
Mullvad liefert in der Datei mullvadconfig.zip, die notwendigen Schlüssel (ca.crt, mullvad.crt, mullvad.key) als auch eine Konfigurationsdatei (mullvad_linux.conf) mit, die später angepasst werden muss.<br />
<br />
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:<br />
<br />
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.<br />
<br />
Als unverbindliche Richtschnur für Linux:<br />
<code><br />
scp mullvadconfig.zip root@<ipv4 des Gateways>:/root<br />
</code><br />
<br />
Danach loggen wir uns auf dem Gateway ein und entpacken die Datei (nicht vergessen unzip zu installieren):<br />
<code><br />
ssh root@<ipv4 des Gateways><br />
<br />
unzip mullvadconfig.zip<br />
<br />
cd <Kundennummernverzeichnis><br />
<br />
cp * /etc/openvpn<br />
</code><br />
<br />
''/etc/openvpn/'' sollte mit dem Inhalt des entpackten mullvadconfig.zip Archivs dann so aussehen:<br />
<pre><br />
ca.crt crl.pem mullvad.crt mullvad.key mullvad_linux.conf mullvad-up mullvad_windows.conf.ovpn <br />
</pre><br />
<br />
'''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.<br />
<br />
Wir legen ein benutzerspezifisches start-up Script namens mullvad-up an:<br />
<code><br />
vi /etc/openvpn/mullvad-up<br />
</code><br />
<br />
und füllen sie mit folgendem Inhalt:<br />
<pre><br />
#!/bin/bash<br />
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE<br />
</pre><br />
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.<br />
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.<br />
<br />
Das Skript mullvad-up muss ferner ausführbar sein:<br />
<code><br />
chmod +x /etc/openvpn/mullvad-up<br />
</code><br />
<br />
Dieses spezifische Routing muss zwingend in mullvad_linux.conf eingepflegt werden:<br />
<code><br />
vi /etc/openvpn/mullvad_linux.conf<br />
</code><br />
<br />
und hier die Konfiguration entsprechend geändert werden:<br />
<pre><br />
.<br />
.<br />
.<br />
# Allow calling of built-in executables and user-defined scripts.<br />
script-security 2<br />
<br />
# Parses DHCP options from openvpn to update resolv.conf<br />
#up /etc/openvpn/update-resolv-conf<br />
#down /etc/openvpn/update-resolv-conf<br />
<br />
# Enable Freifunk specific Routing<br />
route-noexec<br />
route-delay 3<br />
route-up /etc/openvpn/mullvad-up<br />
.<br />
.<br />
.<br />
</pre><br />
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.<br />
<br />
Wer möchte, kann in mullvad_linux.conf auch Länder definieren, über die der VPN Traffic laufen soll (Ein- /Auskommentieren).<br />
<br />
Der openvpn Tunnel kann nun testweise gestartet werden:<br />
<code><br />
cd /etc/openvpn<br />
<br />
/usr/sbin/openvpn mullvad_linux.conf &<br />
</code><br />
<br />
und sollte exemplarisch und im Auszug folgendes zurück liefern:<br />
<pre><br />
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<br />
Sun Sep 6 12:45:20 2015 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08<br />
Sun Sep 6 12:45:20 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts<br />
.<br />
.<br />
.<br />
Sun Sep 6 12:45:23 2015 /sbin/ip link set dev tun0 up mtu 1500<br />
Sun Sep 6 12:45:23 2015 /sbin/ip addr add dev tun0 10.114.0.45/16 broadcast 10.114.255.255<br />
Sun Sep 6 12:45:23 2015 /sbin/ip -6 addr add fdef:e287:a479:72::102b/112 dev tun0<br />
Sun Sep 6 12:45:23 2015 /etc/openvpn/mullvad-up tun0 1500 1558 10.114.0.45 255.255.0.0 init<br />
Sun Sep 6 12:45:23 2015 Initialization Sequence Completed<br />
</pre><br />
Wichtig ist hierbei, dass in der vorletztes Zeile unser Freifunk-spezifisches Routing durchgeführt wird.<br />
<br />
Das VPN-Gateway sollte nun als Default Route in der fff-Routingtabelle auftauchen:<br />
<code><br />
ip route show table fff | grep default<br />
</code><br />
<br />
Exemplarisch wäre eine Ausgabe für das Tunnel-Device tun0 und dem VPN-Gateway 10.114.0.1:<br />
<pre><br />
default via 10.114.0.1 dev tun0<br />
</pre><br />
<br />
Auch ein ifconfig Eintrag für das Tunnel Device...<br />
<code><br />
ifconfig<br />
</code><br />
<br />
...sollte jetzt existieren (Exemplarisch und im Auszug):<br />
<pre><br />
.<br />
.<br />
.<br />
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 <br />
inet addr:10.114.0.76 P-t-P:10.114.0.76 Mask:255.255.0.0<br />
inet6 addr: fdad:bdef:735d:72::104a/112 Scope:Global<br />
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1<br />
RX packets:1012476 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:640206 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:100 <br />
RX bytes:1250196616 (1.1 GiB) TX bytes:84979294 (81.0 MiB)<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
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:<br />
<code><br />
vi /etc/rc.local <br />
</code><br />
<br />
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:<br />
<pre><br />
# launch vpn with 5 seconds delay<br />
(sleep 5; /usr/sbin/openvpn /etc/openvpn/mullvad_linux.conf >> /var/log/mullvad_vpn.log &) &<br />
</pre><br />
<br><br />
<br />
=== NordVPN ===<br />
NordVPN liefert die Datei config.zip mit, die für jeden verwendbaren VPN-Server eine seperate Konfigurationsdatei enthält.<br />
<br />
'''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.<br />
<br />
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.<br />
<br />
Als unverbindliche Richtschnur für Linux:<br />
<code><br />
scp config.zip root@<ipv4 des Gateways>:/root<br />
</code><br />
<br />
Und entpacken diese auf dem Gateway:<br />
<code><br />
cd ~<br />
<br />
mkdir nordvpn-configs<br />
<br />
mv config.zip nordvpn-configs<br />
<br />
cd nordvpn-configs<br />
<br />
unzip config.zip<br />
</code><br />
<br />
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.<br />
<br />
Im Beispiel nehmen wir se1.nordvpn.com.udp1194.ovpn und passen Sie zunächst Freifunk-spezifisch an (siehe Aussperr-Hinweis oben):<br />
<br />
<code><br />
vi se1.nordvpn.com.udp1194.ovpn<br />
</code><br />
<br />
Ä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:<br />
<pre><br />
.<br />
.<br />
.<br />
# Provide Username and Password<br />
auth-user-pass /etc/openvpn/nordvpn-pw<br />
.<br />
.<br />
.<br />
# Allow calling of built-in executables and user-defined scripts.<br />
script-security 2<br />
<br />
# Enable Freifunk specific Routing<br />
route-noexec<br />
route-delay 3<br />
route-up /etc/openvpn/nordvpn-up<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
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:<br />
<code><br />
cp se1.nordvpn.com.udp1194.ovpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf<br />
</code><br />
<br />
Hier legen wir noch unser Freifunk Startskript und unsere Password Datei an und machen das Skript ausführbar:<br />
<code><br />
touch /etc/openvpn/nordvpn-up<br />
<br />
touch /etc/openvpn/nordvpn-pw<br />
<br />
chmod +x /etc/openvpn/nordvpn-up<br />
</code><br />
<br />
Man öffnet nordvpn-up...<br />
<code><br />
vi /etc/openvpn/nordvpn-up<br />
</code><br />
<br />
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):<br />
<pre><br />
#!/bin/bash<br />
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE<br />
</pre><br />
<br />
Nun öffnet man nordvpn-pw:<br />
<code><br />
vi /etc/openvpn/nordvpn-pw<br />
</code><br />
<br />
Und legt in der ersten Zeile der Datei seinen NordVPN Usernamen und in der zweiten Zeile sein NordVPN Passwort ab:<br />
<pre><br />
(Username bei NordVPN)<br />
(Password bei NordVPN)<br />
</pre><br />
<br />
Der Tunnel kann nun testweise gestartet werden (hier im Beispiel mit der Konfigurationsdatei se1.nordvpn.com.udp1194.ovpn)<br />
<code><br />
openvpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf &<br />
</code><br />
<br />
Und sollte aufgebaut werden:<br />
<pre><br />
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<br />
.<br />
.<br />
.<br />
Sun Sep 27 09:07:15 2015 /sbin/ip link set dev tun0 up mtu 1500<br />
Sun Sep 27 09:07:15 2015 /sbin/ip addr add dev tun0 local 10.8.8.226 peer 10.8.8.225<br />
Sun Sep 27 09:07:18 2015 Initialization Sequence Completed<br />
</pre><br />
<br />
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:<br />
<code><br />
vi /etc/rc.local <br />
</code><br />
<br />
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:<br />
<pre><br />
# launch vpn with 5 seconds delay<br />
(sleep 5; cd /etc/openvpn ; /usr/sbin/openvpn se1.nordvpn.com.udp1194.ovpn.conf >> /var/log/nordvpn.log &) &<br />
</pre><br />
Die Beispiel-Konfigurationsdatei (se1.nordvpn.com.udp1194.ovpn.conf) muss entsprechend angepasst werden.<br />
<br><br />
== DNS Server ==<br />
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.<br />
<br />
----<br />
<br />
'''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.'''<br />
<br />
----<br />
<br />
Hierfür editieren wir die Datei named.conf.options...<br />
<code><br />
vi /etc/bind/named.conf.options<br />
</code><br />
<br />
...und tragen die DNS Server, die wir anfragen wollen, wenn wir die Information nicht selber haben, als forwarders ein:<br />
<pre><br />
.<br />
.<br />
.<br />
forwarders {<br />
10.50.32.1;<br />
10.50.32.2;<br />
8.8.8.8;<br />
};<br />
allow-query { <br />
127.0.0.1/8; <br />
10.0.0.0/8; <br />
};<br />
.<br />
.<br />
. <br />
</pre><br />
In diesem Fall werden die Freifunk Gateways ro1 (10.50.32.1) und fff-nue1 (10.50.32.2) der Fürther Hood als auch Google DNS (8.8.8.8) als Forwarders definiert. Für andere Hoods muss die lokale Adresse der Freifunk DNS Server unter [[Portal:Netz]] ermittelt werden (z.B. 10.50.48.1 für ro1 in der Ansbacher Hood).<br />
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".<br />
<br />
Neustart des DNS-Servers mit der neuen Konfiguration:<br />
<code><br />
/etc/init.d/bind9 restart<br />
</code><br />
<br />
Testen können wir, indem wir vom DNS Server des Gateways (localhost/127.0.0.1) eine DNS-Auflösung abfragen. <br />
<br />
Ein DNS Resolve für freifunk-franken.de ...<br />
<code><br />
dig @127.0.0.1 freifunk-franken.de<br />
</code><br />
<br />
...sollte von uns selber (Server localhost; 127.0.0.1) beantwortet werden:<br />
<pre><br />
;; global options: +cmd<br />
<br />
;; Got answer:<br />
<br />
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5819<br />
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1 <br />
;; OPT PSEUDOSECTION:<br />
; EDNS: version: 0, flags:; udp: 4096<br />
<br />
;; QUESTION SECTION:<br />
;freifunk-franken.de. IN A<br />
;; ANSWER SECTION:<br />
freifunk-franken.de. 3599 IN A 31.172.113.113 <br />
.<br />
. <br />
.<br />
;; Query time: 117 msec<br />
;; SERVER: 127.0.0.1#53(127.0.0.1)<br />
;; WHEN: Tue Sep 08 14:16:32 EEST 2015<br />
;; MSG SIZE rcvd: 275<br />
</pre><br />
<br><br />
<br />
== B.A.T.M.A.N Gateway Selection ==<br />
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.<br />
<br />
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:<br />
* Bandbreite der Netzanbindung (z.B. 100 Mbit/sec, gesplittet in 50 Mbit/sec up/down)<br />
* 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)<br />
* Erfahrungswerten / eigenes Ermessen<br />
* Bandbreite, bei dem der Gateway Prozessor ausgelastet ist<br />
<br />
Eventuell muss zuerst bc nachinstalliert werden, falls nicht vorhanden:<br />
<code><br />
apt-get install bc<br />
</code><br />
<br />
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.<br />
<br />
Importieren des Skripts aus einer Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/dyn_announce_gw_bw.sh -P /usr/local/bin/<br />
</code><br />
<br />
Alternativ kann das Skript auch als leere Datei erstellt werden:<br />
<code><br />
touch /usr/local/bin/dyn_announce_gw_bw.sh<br />
</code><br />
<br />
Wir machen das Skript ausführbar und öffnen die Datei:<br />
<code><br />
chmod +x /usr/local/bin/dyn_announce_gw_bw.sh<br />
<br />
vi /usr/local/bin/dyn_announce_gw_bw.sh<br />
</code><br />
<br />
Und Füllen dieses mit Inhalt oder editieren den importierten Inhalt:<br />
<pre><br />
#!/bin/bash<br />
gwsel_lockfile="/tmp/gwsel_lockfile" # lockfile to allow for low bandwidth settings <br />
<br />
if [ -z "$1" ]; then<br />
echo<br />
echo "usage: $0 <network-interface> <update_interval [sec]> <total BW up [Mbit/sec]> <total BW down [Mbit/sec]>"<br />
echo<br />
echo "e.g. $0 eth0 60 10 10"<br />
echo<br />
exit<br />
fi<br />
<br />
while true<br />
do<br />
if [ ! -e ${gwsel_lockfile} ]; then # lockfile not present<br />
# Bandwidth currently used (time averaged)<br />
R1=$(cat "/sys/class/net/$1/statistics/rx_bytes")<br />
T1=$(cat "/sys/class/net/$1/statistics/tx_bytes")<br />
sleep "$2"<br />
R2=$(cat "/sys/class/net/$1/statistics/rx_bytes")<br />
T2=$(cat "/sys/class/net/$1/statistics/tx_bytes")<br />
TkbitPS=$(echo "scale=0; ($T2 - $T1) / 1024 * 8 / $2" | bc -l)<br />
RkbitPS=$(echo "scale=0; ($R2 - $R1) / 1024 * 8 / $2" | bc -l)<br />
# echo "BW used -- up $1: $TkbitPS kBit/s; down $1: $RkbitPS kBit/s"<br />
<br />
# Remaining bandwidth available; cut-off negative values<br />
Tavail_kbitPS=$(echo "scale=0; if (($3 * 1024 - $TkbitPS) >0) ($3 * 1024 - $TkbitPS) else 0" | bc -l)<br />
Ravail_kbitPS=$(echo "scale=0; if (($4 * 1024 - $RkbitPS) >0) ($4 * 1024 - $RkbitPS) else 0" | bc -l)<br />
# echo "BW available -- up $1: $Tavail_kbitPS kBit/s; down $1: $Ravail_kbitPS kBit/s"<br />
else # lockfile present<br />
Tavail_kbitPS=0<br />
Ravail_kbitPS=0<br />
sleep "$2"<br />
fi<br />
<br />
for bat in /sys/class/net/bat*; do<br />
iface=${bat##*/}<br />
batctl -m $iface gw_mode server "${Ravail_kbitPS}kbit/${Tavail_kbitPS}kbit" <br />
done<br />
done<br />
</pre><br />
<br />
Das Skript übernimmt als Parameter:<br />
* Netzwerkinterface, das es zu überwachen gilt (i.d.R. eth0)<br />
* 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)<br />
* Upload Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)<br />
* Download Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)<br />
<br />
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 olsr Defaultroute mit geringer Bandbreite verfügbar ist.<br />
<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.:<br />
<code><br />
/usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10<br />
</code><br />
<br />
Um die Gateway Selection beim Systemsstart zu aktivieren, können wir das Skript z.B. in rc.local aufrufen:<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
um dort, leicht zeitverzögert, o.a. Befehl einzupflegen, wobei die Parametrisierung noch Gateway-spezifisch angepasst werden muss:<br />
<pre><br />
.<br />
.<br />
.<br />
#enable batman GW selection with 15 seconds delay<br />
(sleep 15; /usr/local/bin/dyn_announce_gw_bw.sh eth0 300 12 10) &<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
ACHTUNG! Bei mehreren bat Interfaces (weil man in mehreren Hoods Gateway ist) muss diese Einstellung für jedes Gateway gesetzt werden, hier muss das Script unbedingt überarbeitet werden!<br />
<br />
<pre><br />
batctl -m $batX gw_mode xxmbit/xxmbit<br />
</pre><br />
<br />
und dies für jedes batX Interface. Das Script muss daraufhin noch angepasst werden.<br />
<br />
<br />
auf den Routern kann der vorselektierte Gateway mit <br />
<br />
<code><br />
batctl gwl<br />
</code><br />
<br />
angeguckt werden. Ich vermute das der Gateway mit den Pfeil vorne der vorselektierte Gateway ist, allerdings machen erste beobachtete Daten bisher in meinen Augen noch keinen wirklichen Sinn.<br />
<br><br />
<br />
== DHCP Server ==<br />
Die DHCP Konfiguration kann schon mal vorbereitet werden, sollte aber erst mit als letzter Schritt scharf geschaltet werden. Ein DHCP-Server, der Clients nicht funktionierende DNS-Server oder ein nicht funktionierendes Gateway mitteilt, sperrt diese aus dem Freifunk Netz aus.<br />
<br />
In isc-dhcp-server definieren wir ...<br />
<code><br />
vi /etc/default/isc-dhcp-server<br />
</code><br />
<br />
... das der DHCP Server für das B.A.T.M.A.N Device Anfragen beantworten soll:<br />
<pre><br />
.<br />
.<br />
<br />
INTERFACES="bat0"<br />
.<br />
.<br />
</pre><br />
<br />
Nachfolge Konfiguration wird in auskommentierter Form vorbereitet und sollte erst im letzten Schritt durch Einkommentieren und durch einen Neustart des DHCP Servers...<br />
<code><br />
/etc/init.d/isc-dhcp-server restart<br />
</code><br />
...aktiviert werden.<br />
<br />
Die Konfiguration wird in dhcpd.conf vorgenommen:<br />
<code><br />
vi /etc/dhcp/dhcpd.conf<br />
</code><br />
<br />
und folgender Konfigurationsblock zunächst auskommentiert eingefügt, wobei Gateway und Hood spezifische Änderungen noch eingepflegt werden müssen:<br />
<pre><br />
.<br />
.<br />
.<br />
### Freifunk Franken<br />
#option domain-name "fff.community";<br />
#option domain-name-servers 10.50.16.1;<br />
#authoritative;<br />
### Fuerth<br />
#subnet 10.50.32.0 netmask 255.255.248.0 { # Netzwerk und Netzmaske der Fuerther Hood<br />
# range 10.50.38.0 10.50.39.254; # IP-Range die der DHCP-Server innerhalb der Fuerther Hood verwaltet <br />
# option routers 10.50.32.5; # Default-Gateway, dass Clients mitgeteilt wird <br />
# option domain-name-servers 10.50.32.5, 10.50.32.1; # Name-Server, die Clients mitgeteilt werden<br />
#}<br />
</pre><br />
<br />
Netzwerk und Netzmaske müssen derjenigen der Hood des Gateways entsprechen. Im Beispiel ist dies Fürth, für z.B. Hassberge hieße der Eintrag "subnet 10.50.56.0 netmask 255.255.252.0".<br />
<br />
Der IP-Bereich (Range), die der DHCP-Server in der Hood verwaltet, wurde zuvor unter [[Portal:Netz]] reserviert.<br />
<br />
Unter Routers wird den Clients das Default-Gateway mitgeteilt: Das Gateway, über das Clients das Internet oder eine andere Hood erreichen. In unserem Beispiel routet das aufgesetzte Gateway selber via VPN ins Internet oder via olsr (später) in andere Hoods. Als Default-Gateway wird also die eigene statische IP des Gateways, aus der eigenen Hood, die in [[Portal:Netz]] reserviert wurde, verwendet.<br />
<br />
Ähnlich verhält es sich mit den Nameservern: Auf unserem Gateway wurde ein DNS Server eingerichtet, also kann der domain-name-server unser eigenes Gateway, mit der reservierten statische IP aus der Hood, wie in [[Portal:Netz]], sein. Als Backup empfiehlt sich ein weiterer DNS-Server aus der Hood, in unserem Beispiel ro1 in der Fürther.<br />
<br><br />
<br />
== GRE-Tunnel zu anderen Gateways ==<br />
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]].<br />
<br />
Der GRE-Tunnel wird in /etc/network/interfaces...<br />
<code><br />
vi /etc/network/interfaces<br />
</code><br />
<br />
...mit folgenden noch auf das Gateway anzupassenden Einträgen deklariert:<br />
<pre><br />
auto <tunnel><br />
iface <tunnel> inet static<br />
address <Eigene IPv4 (Freifunk Netz)><br />
pre-up ip -4 tunnel add $IFACE mode gre local <Eigene IPv4 (Internet)> remote <IPv4 des Tunnelpartners (Internet)> ttl 255<br />
#pre-up ip -6 tunnel add $IFACE mode ip6gre local <Eigene IPv6 (Internet)> remote <IPv6 des Tunnelpartners (Internet)> ttl 255<br />
<br />
up ifconfig $IFACE multicast<br />
pointopoint <IPv4 des Tunnelpartners (Freifunk Netz)><br />
post-up iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu<br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.50.0.0/16 table fff<br />
post-up ip rule add to 10.50.0.0/16 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ip rule del from 10.50.0.0/16 table fff<br />
post-down ip rule del to 10.50.0.0/16 table fff<br />
post-down iptables -t mangle -D POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu<br />
post-down iptunnel del $IFACE<br />
</pre><br />
<br />
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.<br />
<br />
'''Beispiel:''' <br />
Um als fff-nue1 einen Tunnel zu ro1 aufzubauen, können die IP-Adressen wie folgt gewählt werden:<br />
<pre><br />
<tunnel> ro1<br />
<Eigene IPv4 (Freifunk Netz)> fff-nue1 10.50.252.1<br />
<IPv4 des Tunnelpartners (Freifunk Netz)> ro1 10.50.252.0<br />
<Eigene IPv4 (Internet)> fff-nue1 31.172.33.99<br />
<IPv4 des Tunnelpartners (Internet)> ro1 176.126.221.7<br />
</pre><br />
<br />
In der Partnerkonfiguration für ro1 werden die Rollen entsprechend vertauscht:<br />
<pre><br />
<tunnel> fff-nue1<br />
<Eigene IPv4 (Freifunk Netz)> ro1 10.50.252.0<br />
<IPv4 des Tunnelpartners (Freifunk Netz)> fff-nue1 10.50.252.1<br />
<Eigene IPv4 (Internet)> ro1 176.126.221.7<br />
<IPv4 des Tunnelpartners (Internet)> fff-nue1 31.172.33.99 <br />
</pre><br />
<br />
Der Tunnel kann über den Aufruf von<br />
<code><br />
ifup <tunnel><br />
</code><br />
...aufgebaut werden, wobei <tunnel> der Name des GRE-Interfaces ist (im Beispiel ro1)<br />
<br />
Nach Aufruf von ifconfig..<br />
<code><br />
ifconfig <br />
</code><br />
sollten wir einen Eintrag für den Tunnel (in diesem Beispiel ro1) vorfinden:<br />
<pre><br />
.<br />
.<br />
.<br />
ro1 Link encap:UNSPEC HWaddr B0-7B-1C-73-30-30-3A-35-00-00-00-00-00-00-00-00 <br />
inet addr:10.50.252.1 P-t-P:10.50.252.0 Mask:255.255.255.255<br />
inet6 addr: fe80::200:5efe:b07b:1c73/64 Scope:Link<br />
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1476 Metric:1<br />
RX packets:160913 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:146654 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0 <br />
RX bytes:66984353 (63.8 MiB) TX bytes:10675001 (10.1 MiB)<br />
.<br />
.<br />
.<br />
</pre><br />
<br><br />
== OLSR ==<br />
=== Basiskonfiguration ===<br />
Mittels OLSR können die Gateways selbstständig Routinginformationen austauschen. Ähnlich wie B.A.T.M.A.N einzelne Router innerhalb einer Hood vermesht (Level 2 Netz), handelt es sich bei olsr um ein mesh zwischen den Gateways (Level 3). Es ermöglicht ein Freifunk Franken internes Routing: z.B. kann eine beliebige IPv4 aus der Nürnberger Hood aus der Fürth Hood heraus erreicht werden.<br />
<br />
Vorlagen können unter Sicherung der Originaldateien wie folgt importiert werden:<br />
<code><br />
mv /etc/default/olsrd /etc/default/olsrd.orig<br />
<br />
mv /etc/olsrd/olsrd.conf /etc/olsrd/olsrd.conf.orig<br />
<br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd -P /etc/default/<br />
<br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd.conf -P /etc/olsrd/<br />
</code><br />
<br />
Zunächst zeigen wir die Interfaces an, unter dem wir olsr Routing Informationen austauschen:<br />
<code><br />
vi /etc/default/olsrd<br />
</code><br />
<br />
Im Beispiel wird über die 2 GRE-Tunnel nue1 und ro1 ausgetauscht, dies muss entsprechend der GRE-Tunnel Konfiguration angepasst werden: <br />
<pre><br />
.<br />
.<br />
#<br />
# Uncomment the next line run olsrd automatically at startup<br />
#<br />
START_OLSRD="YES"<br />
<br />
#<br />
# Uncomment the next line to force-configure the wifi interface to be setup<br />
# for ad-hoc mode using the /usr/sbin/olsrd-adhoc-setup script whenever olsrd<br />
# is started.<br />
#<br />
SETUP_ADHOC="NO"<br />
.<br />
.<br />
.<br />
#<br />
# Specify the network interfaces that olsrd will run on, this will most likely<br />
# be your wifi interface.<br />
#<br />
MESH_IF="nue1 ro1" <br />
.<br />
.<br />
</pre><br />
<br />
<br />
Weiter wird dann hier ...<br />
<code><br />
vi /etc/olsrd/olsrd.conf<br />
</code><br />
... konfiguriert. <br />
Da unser Beispiel-Gateway ins Netz der Fürther Hood eingebunden ist, teilen wir dies andern Gateways über den Eintrag 10.50.32.0/21 mit:<br />
<pre><br />
.<br />
.<br />
.<br />
# HNA IPv4 routes<br />
# syntax: netaddr netmask<br />
# Example Internet gateway:<br />
# 0.0.0.0 0.0.0.0<br />
<br />
Hna4<br />
{<br />
# Internet gateway:<br />
# 0.0.0.0 0.0.0.0<br />
# more entries can be added:<br />
# 192.168.1.0 255.255.255.0<br />
10.50.32.0/21<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Hier wird das olsr Webinterface auf port 8080 konfiguriert:<br />
<br />
<pre><br />
.<br />
.<br />
.<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
# defaults to 1978<br />
PlParam "Port" "8080"<br />
# if you dont set these, the default is to listen only on the loopback device<br />
#PlParam "Host" "80.23.53.22"<br />
#PlParam "Net" "10.0.0.0 255.0.0.0"<br />
PlParam "Net" "0.0.0.0 0.0.0.0"<br />
#PlParam "Host" "127.0.0.1"<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Ferner wird der VPN-Tunnel (hier tun0) per persönlich angepasstem ping Kommando auf sein Funktion hin überwacht. Sollte der VPN-Tunnel ausfallen, ermöglicht olsr im Zusammenspiel mit der Routing Priorisierung (s.u) und der OpenVPN Start-/Stop Automatik (s.u.) ein automatisches Re-Routing:<br />
<pre><br />
.<br />
.<br />
.<br />
LoadPlugin "olsrd_dyn_gw.so.0.5"<br />
{<br />
# Here parameters are set to be sent to the<br />
# plugin. Theese are on the form "key" "value".<br />
# Parameters ofcause, differs from plugin to plugin.<br />
# Consult the documentation of your plugin for details.<br />
<br />
# Example: dyn_gw params<br />
<br />
# how often to check for Internet connectivity<br />
# defaults to 5 secs<br />
PlParam "Interval" "5"<br />
<br />
# if one or more IPv4 addresses are given, do a ping on these in<br />
# descending order to validate that there is not only an entry in<br />
# routing table, but also a real internet connection. If any of<br />
# these addresses could be pinged successfully, the test was<br />
# succesful, i.e. if the ping on the 1st address was successful,the<br />
# 2nd won't be pinged<br />
PlParam "Ping" "8.8.8.8"<br />
PlParam "Ping" "82.165.230.17"<br />
PlParam "pingcmd" "ping -c 1 -q -I tun0 %s"<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Folgender Konfigurationsblock muss ans Ende der Konfigurationsdatei angefügt werden. Es ermöglich olsr die Manipulation der fff-Routingtabelle:<br />
<pre><br />
.<br />
.<br />
.<br />
# Specify the proto tag to be used for routes olsr inserts into kernel<br />
# currently only implemented for linux<br />
# valid values under linux are 1 .. 254<br />
# 1 gets remapped by olsrd to 0 UNSPECIFIED (1 is reserved for ICMP redirects)<br />
# 2 KERNEL routes (not very wise to use)<br />
# 3 BOOT (should in fact not be used by routing daemons)<br />
# 4 STATIC<br />
# 8 .. 15 various routing daemons (gated, zebra, bird, & co)<br />
# (defaults to 0 which gets replaced by an OS-specific default value<br />
# under linux 3 (BOOT) (for backward compatibility)<br />
#<br />
RtProto 8<br />
#<br />
# Specifies the routing Table olsr uses<br />
# RtTable is for host routes, RtTableDefault for the route to the default<br />
# internet gateway (2 in case of IPv6+NIIT) and RtTableTunnel is for<br />
# routes to the ipip tunnels, valid values are 1 to 254<br />
# There is a special parameter "auto" (choose default below)<br />
# (with smartgw: default is 254/223/224)<br />
# (without smartgw: default is 254/254/254, linux main table)<br />
#<br />
RtTable 10<br />
RtTableDefault 10<br />
RtTableTunnel 10<br />
#<br />
# Specifies the policy rule priorities for the three routing tables and<br />
# a special rule for smartgateway routing (see README-Olsr-Extensions)<br />
# Priorities can only be set if three different routing tables are set.<br />
# if set the values must obey to condition<br />
# RtTablePriority < RtTableDefaultOlsrPriority<br />
# < RtTableTunnelPriority < RtTableDefaultPriority.<br />
# There are two special parameters, "auto" (choose fitting to SmartGW<br />
# mode) and "none" (do not set policy rule)<br />
# (with smartgw: default is none/32776/32776/32796)<br />
# (without smartgw: default is none/none/none/none)<br />
#<br />
# RtTablePriority auto<br />
# RtTableDefaultOlsrPriority auto<br />
# RtTableTunnelPriority auto<br />
# RtTableDefaultPriority auto<br />
</pre><br />
<br />
<br />
Das Freifunk Franken intere Routing kann nun getestet werden.<br />
<br />
Zunächst einmal starten wir olsr neu:<br />
<code><br />
/etc/init.d/olsrd restart<br />
</code><br />
<br />
<br />
Die Routinginformationen des olsr-meshes sollten in der fff-Routingtabelle auftauchen:<br />
<code><br />
ip route show table fff<br />
</code><br />
<br />
Exemplarischer Auszug:<br />
<pre><br />
.<br />
.<br />
.<br />
10.50.32.1 via 10.50.32.1 dev ro1 proto gated metric 2 onlink <br />
10.50.32.2 via 10.50.32.2 dev nue1 proto gated metric 2 onlink <br />
10.50.40.0/21 via 10.50.32.1 dev ro1 proto gated metric 2 onlink <br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Eine IP4 aus der Nürnberger Hood (10.50.40.0/21) sollte z.B. von Fürth aus (10.50.32.0/21) erreichbar sein:<br />
<br />
<code><br />
ping 10.50.40.3<br />
</code><br />
<br />
Antwort:<br />
<pre><br />
PING 10.50.40.3 (10.50.40.3) 56(84) bytes of data.<br />
64 bytes from 10.50.40.3: icmp_seq=1 ttl=63 time=42.2 ms<br />
64 bytes from 10.50.40.3: icmp_seq=2 ttl=63 time=42.7 ms<br />
^C<br />
--- 10.50.40.3 ping statistics ---<br />
2 packets transmitted, 2 received, 0% packet loss, time 1000ms<br />
rtt min/avg/max/mdev = 42.279/42.516/42.753/0.237 ms<br />
</pre><br />
<br><br />
=== OpenVPN Start/Stop Automatik ===<br />
OLSR testet mit dem Dynamic Gateway Plugin, ob die Default Route über den OpenVPN Tunnel noch funktioniert, indem regelmässig teilweise mehrere verschiedene Ziele über den Tunnel angepingt werden. Sollte der OpenVPN Tunnel nicht mehr funktionieren, baut OLSR eine neue Default-Route zu einem anderem Gateway auf, über das dann der Internet-Traffic läuft. Beide Default-Routen, die über den OpenVPN Tunnel und die von OLSR, existieren parallel, wobei zunächst weiterhin die OpenVPN Verbindung verwendet wird.<br />
<br />
Da die OpenVPN Verbindung ausgefallen ist, aber trotzdem noch als bevorzugte Default-Route eingetragen ist, ist die Internetanbindung bis die Störung VPN-Server seitig behoben ist, trotzdem nicht verfügbar. <br />
<br />
Für diesen Anwendungsfall wird ein Skript vorgeschlagen, dass die Funktion des OpenVPN Tunnels überwacht und den Tunnel (und die OpenVPN Default-Route) bei Nicht-Funktion abbaut. Um die Funktion zu überprüfen werden in regelmässigen Abständen 2 verschiedene Ziele über den Tunnel angepingt. Scheitert dies, wird der Tunnel für einen gewissen Zeitraum abgebaut, in dem dann stattdessen das OLSR Dynamic Gateway Plugin das Routing übernimmt. Danach wird die Verbindung wieder aufgebaut. Anschliessend wird überprüft, ob der OpenVPN-Tunnel wieder funktioniert. Tut er es nicht, wird er wieder abbgebaut, funktioniert er, bleibt er bis zur Detektion der nächsten Störung als Internetanbindung erhalten.<br />
<br />
Man importiert die Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/auto_start-stop_ovpn.sh -P /usr/local/bin/<br />
</code><br />
<br />
Alternativ kann man statt der Vorlage auch eine leere Datei anlegen:<br />
<code><br />
touch /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
Man macht das Skript ausführbar:<br />
<code><br />
chmod +x /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
<br />
Nun öffnet man die Datei im Editor ...<br />
<code><br />
vi /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
... und füllt sie mit Inhalt oder editiert den importierten Inhalt:<br />
<pre><br />
#!/bin/bash<br />
IF="tun0" # Interface used for ping<br />
ping1_target="8.8.8.8" # IP no. 1 used for ping<br />
ping2_target="82.165.229.31" # IP no. 2 used for ping<br />
ping_interval="5" # waiting time in-between two pings<br />
switchback_interval="3600" # waiting time for interface to recover before probing again<br />
start_grace="10" # waiting time to allow for tunnel restart<br />
logfile="/dev/null" # logfile for debug<br />
<br />
openvpn_stop-cmd () { # command used disabling tunnel<br />
#service openvpn stop # ubuntu<br />
/etc/init.d/openvpn stop # debian<br />
#killall openvpn # hardcore<br />
}<br />
<br />
openvpn_start-cmd () { # command used enabling tunnel<br />
#service openvpn start # ubuntu<br />
/etc/init.d/openvpn start # debian<br />
#openvpn /etc/openvpn/*.conf & # hardcore<br />
}<br />
<br />
ping1 () {<br />
echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF" &>> $logfile<br />
ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF &>> $logfile<br />
ping1_ExitCode=$?<br />
echo "$(date): Exit Status: ${ping1_ExitCode}" &>> $logfile<br />
}<br />
<br />
ping2 () {<br />
echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF" &>> $logfile<br />
ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF &>> $logfile<br />
ping2_ExitCode=$?<br />
echo "$(date): Exit Status: ${ping2_ExitCode}" &>> $logfile<br />
}<br />
<br />
<br />
while true<br />
do<br />
# wait for interface build-up, if interface not present<br />
if [ ! -h "/sys/class/net/$IF" ]; then<br />
echo "$(date): Interface $IF not detected. Waiting ${start_grace} seconds." &>> $logfile<br />
sleep ${start_grace}<br />
fi<br />
<br />
# perform ping<br />
ping1<br />
ping2<br />
<br />
# check if ping successful<br />
if ([[ ${ping1_ExitCode} -eq 0 ]] || [[ ${ping2_ExitCode} -eq 0 ]]); then<br />
sleep ${ping_interval}<br />
else<br />
logger -t "$0" ${ping1_target} and ${ping2_target} not reached via interface $IF.<br />
echo "$(date): ${ping1_target} and ${ping2_target} not reached via interface $IF." &>> $logfile<br />
<br />
if [ -h "/sys/class/net/$IF" ]; then<br />
logger -t "$0" Stopping interface $IF.<br />
echo "$(date): Stopping interface $IF." &>> $logfile<br />
openvpn_stop-cmd &>> $logfile<br />
fi<br />
<br />
sleep ${switchback_interval}<br />
<br />
if [ ! -h "/sys/class/net/$IF" ]; then<br />
logger -t "$0" Restoring interface $IF to probe for recovery.<br />
echo "$(date): Restoring interface $IF to probe for recovery." &>> $logfile<br />
openvpn_start-cmd &>> $logfile<br />
fi<br />
fi<br />
done<br />
</pre><br />
<br />
Hierbei können im Skript folgende Anpassungen vorgenommen werden:<br />
*openvpn_stop-cmd: Der Befehl, mit dem der OpenVPN Tunnel '''abgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ als Prozess gekillt werden.<br />
*openvpn_start-cmd: Der Befehl, mit dem der OpenVPN tunnel '''aufgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ per openvpn Kommandozeilenaufruf gestartet werden.<br />
*IF: Das OpenVPN Tunnel Device. Normalerweise ist das tun0.<br />
*ping1_target,ping2_target: Die IP-Adressen die über das Tunnel-Interface IF angepingt werden, um den Tunnel auf Funktion zu überprüfen. Vorauswahl: Google DNS und Web.de<br />
*ping_interval: Der zeitliche Anstand zwischen zwei Ping-Versuchen. Vorauswahl: 5 Sekunden.<br />
*switchback_interval: Der Zeitraum, den der Tunnel abgebaut bleibt, sollte er als nicht-funktionierend erkannt worden sein. Es wird ein träges Verhalten empfohlen. Vorauswahl: 3600 Sekunden.<br />
*start_grace: Der Zeitraum, der dem Tunnel zum Starten eingeräumt wird. Die Timer-Funktion macht ferner das Skript gegen Restarts des Tunnels unempfindlich.<br />
*logfile: Für Debug Zwecke kann man detaillierte Ausgaben hier in eine Datei umleiten.<br />
<br />
Das Skript selber kann manuell ...<br />
<code><br />
auto_start-stop_ovpn.sh &<br />
</code><br />
<br />
...und bei jedem Systemstart mit gestartet werden, indem es z.B. in /etc/rc.local ...<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
...wie folgt eingetragen wird:<br />
<pre><br />
.<br />
.<br />
.<br />
#enable tunnel monitoring with 60 seconds delay<br />
(sleep 60; auto_start-stop_ovpn.sh &) &<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Getestet werden kann das Skript z.B., indem man sich alle Default-Routen der fff-Tabelle anzeigen lässt: <br />
<code><br />
watch "ip route show table fff | grep default"<br />
</code><br />
<br />
und parallel dazu auf einer zweiten Shell das openvpn deaktiviert:<br />
<code><br />
killall openvpn<br />
</code><br />
<br />
Es sollte eine neue Default-Route zu einem anderen Gateway aufgebaut werden, über die der Internet-Traffic dann läuft. Die Route über den OpenVPN Tunnel sollte verschwinden. Nach der eingestellten Zeit wird der OpenVPN Tunnel durch das Skript wieder reaktiviert. Danach existieren beide Default-Routen parallel, bis OLSR seine Route automatisch wieder abbaut. Die OpenVPN Default-Route bleibt und ist wieder aktiv.<br />
<br><br />
=== Priorisieren von OLSR Routen ===<br />
OLSR erstellt die fff-Routingtabelle selbstständig, indem es die Linkqualität anhand von Algorithmen bewertet. Diese Bewertung ist recht volatil, was dazu führen kann, das die von OLSR ausgesuchte Default-Route häufig wechselt. Für die verbundenen Clients wechselt jedes mal die externe Internet IP mit, je nachdem über welches Gateway OLSR den Internet-Traffic gerade abwirft. Bei IP-Wechsel stoppen z.B. Downloads aus dem Internet, stoppen Videos im Abspielen, werden ssh Verbindungen gekappt.<br />
<br />
Um diese Dynamik nicht allzu schnell zu gestalten, empfiehlt es sich OLSR eine oder zwei Default-Routen mitzuteilen, die bevorzugt verwendet werden. Zusätzlich wird NatThreshold, einen Schwellwert den die neue Default-Route besser sein muss als die alte, bevor gewechselt wird, definiert.<br />
<br />
Dies geschieht über Gewichtungsfaktoren in olsrd.conf:<br />
<br />
<code><br />
vi /etc/olsrd/olsrd.conf<br />
</code><br />
<br />
Routen kann man im Abschnitt InterfaceDefaults priorisieren. <br />
Hier können Gewichtungsfaktoren für die GRE-Tunnel zu anderen Gateways eingeführt werden, mit denen die Link-Qualität beeinflusst werden kann:<br />
<pre><br />
.<br />
.<br />
.<br />
# If a certain route should be preferred<br />
# or ignored by the mesh, the Link Quality<br />
# value of a node can be multiplied with a factor<br />
# entered here. In the example the route<br />
# using 192.168.0.1 would rather be ignored.<br />
# A multiplier of 0.5 will result in a small<br />
# (bad) LinkQuality value and a high (bad)<br />
# ETX value.<br />
<br />
# preferred link<br />
LinkQualityMult <tunnel1_ip> 0.99<br />
<br />
# preferred link<br />
LinkQualityMult <tunnel2_ip> 0.99<br />
<br />
# This multiplier applies to all other nodes<br />
LinkQualityMult default 0.7<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Im Beispiel werden alle Routen herabgestuft (Faktor 0.7), mit der Ausnahme derer die über <tunnel1_ip> oder <tunnel2_ip> laufen (Faktor 0.99). <tunnel_ip1> sind dabei die Point-to-Point Partner IPs der GRE Tunnel der jeweiligen Gateways im Freifunk Netz. Die nicht herabgestuften Routen können analog als priorisiert betrachtet werden. Für eine Priorisierung der Route von nue1 zu ro1 wäre die <tunnel1/2_ip> z.B. die 10.50.252.1 (Vgl. [[Portal:Netz]]).<br />
<br />
NatThreshold wird im Hauptabschnitt von olsrd.conf definiert:<br />
<pre><br />
.<br />
.<br />
# If the NAT-Endpoint (the preferred 0/0 HNA emitting node)<br />
# is to be changed, the ETX value of the current 0/0 is<br />
# multiplied with the NatThreshold value before being<br />
# compared to the new one<br />
# The parameter can be a value between 0.1 and 1.0, but<br />
# should be close to 1.0 if changed.<br />
<br />
NatThreshold 0.7<br />
.<br />
.<br />
</pre><br />
<br />
Im Beispiel muss die Linkqualität der neuen Default-Route um 30% besser bewertet als die aktuelle sein, bevor die Default-Route gewechselt wird.<br />
<br />
Die Änderungen werden nach Neustart von OLSR aktiv:<br />
<code><br />
/etc/init.d/olsrd restart<br />
</code><br />
<br><br />
= Einbringen des Gateways in die Hood / Keyserver =<br />
Abschliessend muss das Gateway im Keyserver als Gateway der entsprechenden Hood eingetragen werden. Hierfür benötigt man einen Keyserver-Administrator => [[Server]].<br />
<br />
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.<br />
<br />
Der DHCP-Server sollte als letzter Schritt aktiviert werden (s.o.)<br />
<br><br />
= Transparent Proxy =<br />
Auf dem Gateway kann (aber muss nicht) ein Proxy-Server installiert werden, der Dateien (z.B. Bilder), die schon mal angefragt wurden, nicht aus dem Internet holt, sondern als "lokal" gespeicherte Datei direkt vom Gateway bereitstellt. Die Clients werden dabei über den Proxy gezwungen, d.h. das Gateway leitet die Anfragen pauschal an den Proxy weiter, welcher entscheidet ob der die Anfrage selber bedient oder Gateway-extern anfragt. <br />
<br />
Die Einrichtung eines Proxys ist '''optional''', d.h. der Proxy ist für die Funktion des Gateways nicht notwendig. Proxy-Server reduzieren Antwortzeiten und Traffic für sich '''häufig''' wiederholende Anfragen (z.B. Spiegel Online, Windows Update).<br />
<br />
'''Hinweis''': <br />
Die Einrichtung eines Proxy ist umstritten, da:<br />
* HTTP-Header, wenn auch in geringem Umfang, verändert werden<br />
* Daten, wenn auch nicht direkt einsehbar, auf dem Gateway gespeichert werden<br />
* Daten nicht unmittelbar von der Originalquelle bezogen werden <br />
* Die Effizienzsteigerung gering ist. Nach Auswertung werden ca. 7% aller unverschlüsselten HTTP-Anfragen von dem Gateway direkt beantwortet. Für diese 7% halbiert sich der benötigte Traffic, wobei ein Großteil aller Webseiten heutzutage verschlüsselt wird und z.Zt. 50% des benötigten Traffics Overhead ist. <br />
* Zusätzliche Ressourcen (RAM, Prozessor) auf dem Gateway benötigt werden <br />
<br />
'''Inkompatiblität''': Die Konfiguration funktioniert z.Zt. nicht im Zusammenspiel mit der "OpenVPN Start/Stop Automatik" und dem automatischen OLSR Re-Routing des Default-Gateways (Dynamic Gateway Plugin).<br />
<br><br />
== Installation ==<br />
Installiert wird der de-facto-Standard squid:<br />
<code><br />
apt-get install squid3<br />
</code><br />
<br />
Für die kommende Konfiguration stoppen wir squid wieder:<br />
<code><br />
/etc/init.d/squid3 stop<br />
</code><br />
<br><br />
== Konfiguration ==<br />
Die mit installiere Konfigurationsdatei squid.conf ist sehr umfangreich und bietet eine gute Dokumentationsbasis, ist damit aber auch etwas unhandlich.<br />
<br />
Aus diesem Grund empfiehlt es sich, die Datei umzubenennen:<br />
<code><br />
mv /etc/squid3/squid.conf /etc/squid3/squid.conf.orig<br />
</code><br />
<br />
Wir importieren die Datei von einer Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/squid.conf -P /etc/squid3/<br />
</code><br />
<br />
Alternativ können wir die Datei auch leer erstellen:<br />
<code><br />
touch /etc/squid3/squid.conf<br />
</code><br />
<br />
Danach öffnen wir die Konfigurationsdatei...<br />
<code><br />
vi /etc/squid3/squid.conf<br />
</code><br />
<br />
...und füllen diese mit Inhalt, der allerdings noch auf das Gateway angepasst werden muss:<br />
<pre> <br />
# cache size in MB / no. of subdirectories / no. of subsubdirectories<br />
cache_dir ufs /var/spool/squid3 100 16 256<br />
<br />
#maximum object size in cache (default: 4 MB)<br />
#maximum_object_size 128 MB<br />
maximum_object_size 4 MB<br />
<br />
# Memory used for caching<br />
cache_mem 32 MB<br />
<br />
# No access log<br />
#access_log /var/log/squid3/access.log combined<br />
access_log none<br />
<br />
# Hostname shown in messages<br />
visible_hostname fff<br />
<br />
# Bind Squid to port ... and configure as transparent proxy <br />
http_port 3128 intercept<br />
# In addition a forward proxy is required<br />
http_port 3129<br />
<br />
refresh_pattern ^ftp: 1440 20% 10080<br />
refresh_pattern ^gopher: 1440 0% 1440<br />
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0<br />
refresh_pattern . 0 20% 4320<br />
<br />
# Allow connects from Freifunk Franken network<br />
acl fff src 10.50.0.0/16 <br />
<br />
# DNS by Freifunk-IP of localhost and Google DNS<br />
dns_nameservers 10.50.32.5 8.8.8.8<br />
<br />
# Bind outgoing address to Freifunk-Server IP to allow for VPN Routing <br />
tcp_outgoing_address 10.50.32.5<br />
udp_outgoing_address 10.50.32.5<br />
<br />
# Privacy options <br />
via off<br />
forwarded_for delete<br />
<br />
# standard http anonymizer<br />
request_header_access From deny all<br />
#request_header_access Referer deny all<br />
#request_header_access User-Agent deny all<br />
<br />
## paranoid http anonymizer<br />
#request_header_access Authorization allow all<br />
#request_header_access Proxy-Authorization allow all<br />
#request_header_access Cache-Control allow all<br />
#request_header_access Content-Length allow all<br />
#request_header_access Content-Type allow all<br />
#request_header_access Date allow all<br />
#request_header_access Host allow all<br />
#request_header_access If-Modified-Since allow all<br />
#request_header_access Pragma allow all<br />
#request_header_access Accept allow all<br />
#request_header_access Accept-Charset allow all<br />
#request_header_access Accept-Encoding allow all<br />
#request_header_access Accept-Language allow all<br />
#request_header_access Connection allow all<br />
#request_header_access All deny all<br />
<br />
# Access controls<br />
acl SSL_ports port 443 # https<br />
acl Safe_ports port 80 # http<br />
acl Safe_ports port 21 # ftp<br />
acl Safe_ports port 443 # https<br />
acl Safe_ports port 70 # gopher<br />
acl Safe_ports port 210 # wais<br />
acl Safe_ports port 1025-65535 # unregistered ports<br />
acl Safe_ports port 280 # http-mgmt<br />
acl Safe_ports port 488 # gss-http<br />
acl Safe_ports port 591 # filemaker<br />
acl Safe_ports port 777 # multiling http<br />
<br />
acl CONNECT method CONNECT<br />
http_access deny !Safe_ports<br />
http_access deny CONNECT !SSL_ports<br />
http_access allow localhost manager<br />
http_access deny manager<br />
http_access allow fff<br />
http_access allow localhost<br />
http_access deny all<br />
</pre><br />
<br />
Hier '''müssen''' angepasst werden:<br />
* cache_dir: Die Gesamtgröße des Caches (hier: 100 MByte) muss so bemessen sein, dass auf der Partition auch bei Maximalgröße des Caches noch Speicher frei bleibt. Squid Standardeinstellung ist 100 MB bei 16 Verzeichnissen und jeweils 256 Unterverzeichnissen. Freier Speicherplatz kann mit "df -h" ermittelt werden.<br />
* dns_nameservers: Hier sollten die '''Freifunk-IPv4''' des Gateways (in diesem Beispiel 10.50.32.5) und eine externe IP (hier Google DNS 8.8.8.8) eingetragen werden. Wichtig ist, '''nicht localhost''' einzutragen, da die Anfrage im Zusammenspiel mit der "outgoing address" (s.u.) über die fff-Routingtabelle laufen muss.<br />
* tcp_outgoing_address und udp_outgoing_address: Diese beide Einträge sind elementar wichtig. Zwar funktioniert der Proxy auch ohne, routet aber nicht über das VPN sondern direkt vom Gateway ins Internet. Damit die fff-Routingtabelle verwendet wird, für die als Default-Gateway eine VPN Verbindung eingerichtet ist, tragen wir hier die Freifunk-IP des Gateways ein (10.50.<irgendwas>). In diesem Beispiel ist die Freifunk-IPv4 des Gateways die 10.50.32.5.<br />
* access_log: Das Access log sollte deaktiviert bleiben (access_log none), da es ein lebendiges Beispiel für Vorratsdatenspeicherung ist und die log-Dateien auch sehr schnell, sehr groß werden.<br />
<br />
Danach erstellen wir die Verzeichnisstruktur des Proxy:<br />
<code><br />
squid3 -z<br />
</code><br />
<br />
Jetzt sind wir fast fertig. Wir starten den Proxy:<br />
<code><br />
/etc/init.d/squid3 start<br />
</code><br />
<br />
Anfragen, die auf Port 80 (http) reinkommen, müssen nun noch auf Port 3128 umgeleitet werden. Auf Port 3128 lauscht unser Proxy, http-Anfragen werden quasi transparent (oder zwangsweise) über den Proxy geleitet :<br />
<code><br />
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
</code><br />
<br />
Damit unsere Portumleitung mit jedem Start von Squid eingerichtet und mit jedem Stopp aufgehoben wird, pflegen wir sie (nicht ganz sauber) im squid start/stop Skript mit ein:<br />
<code><br />
vi /etc/init.d/squid3<br />
</code><br />
<br />
und fügen '''zwei''' iptables Einträge nach dem Start und vor dem Stopp von Squid ein:<br />
<pre><br />
.<br />
.<br />
.<br />
start () {<br />
cache_dir=`find_cache_dir cache_dir`<br />
cache_type=`grepconf cache_dir`<br />
<br />
#<br />
# Create run dir (needed for several workers on SMP)<br />
#<br />
create_run_dir<br />
<br />
#<br />
# Create spool dirs if they don't exist.<br />
#<br />
if test -d "$cache_dir" -a ! -d "$cache_dir/00"<br />
then<br />
log_warning_msg "Creating $DESC cache structure"<br />
$DAEMON -z -f $CONFIG<br />
fi<br />
<br />
umask 027<br />
ulimit -n 65535<br />
cd $cache_dir<br />
start-stop-daemon --quiet --start \<br />
--pidfile $PIDFILE \<br />
--exec $DAEMON -- $SQUID_ARGS < /dev/null<br />
# Use as transparent proxy<br />
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
return $?<br />
}<br />
<br />
stop () {<br />
PID=`cat $PIDFILE 2>/dev/null`<br />
# Use as transparent proxy<br />
iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
start-stop-daemon --stop --quiet --pidfile $PIDFILE --exec $DAEMON <br />
#<br />
# Now we have to wait until squid has _really_ stopped.<br />
#<br />
.<br />
.<br />
.<br />
</pre></div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Liste_bekannter_Aux-FW_Router&diff=5351
Liste bekannter Aux-FW Router
2016-01-20T17:35:24Z
<p>Green: </p>
<hr />
<div>Um den Überblick über die mit Aux-FW geflashten Router zu behalten, wird eine Übersichtstabelle über die bekannten (d.h. zurückgemeldeten) Router geführt.<br />
<br />
{|<br />
! Routername !! Router-MAC !! gemeldet von !! gemeldet am !! Bemerkungen<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1317 Notunterkunft Turnhalle] || 14CC204D4786 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1318 Notunterkunft Turnhalle1] || 30B5C2AC26D8 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1355 ArnsteinerNetz0001] || 30:b5:c2:bd:77:ba || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1716 ArnsteinerNetz0002] || 30.b5:c2:bd:78:86 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1484 ArnsteinerNetz0005] || 30:b5:c2:88:47:14 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1754 ArnsteinerNetz0006] || 30:b5:c2:88:4e:00 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1248 ArnsteinerNetz002] || 30:b5:c2:d9:c8:ae || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1247 ArnsteinerNetz003] || 30:b5:c2:d9:c8:18 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1753 ArnsteinerNetz004] || 30:b5:c2:d9:c6:de || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || reiner AP, kein Mesh, Clientzählung durch Meshrouter "ArnsteinerNetz002" 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=583 WS13W01WR1043] || e8:de:27:fd:2b:aa || [https://netmon.freifunk-franken.de/user.php?user_id=6 delphiN] || 03.11.2015 || Beta 2 Testbetrieb<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1768 HabuRef01] || 30B5C20E8AE0 || [https://netmon.freifunk-franken.de/user.php?user_id=438 DerMichy] || 15.11.2015 || Pending installation in Hammelburg, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1766 Tannenberg01] || 60:E3:27:2A:56:46 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1769 Tannenberg02] || 30:B5:C2:E2:FD:EE || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1770 Tannenberg03] || 60:E3:27:2A:58:E4 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2066 Tannenberg04] || 60:E3:27:59:E3:C8 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 05.01.2016 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1751 AHKRockenbrunner1] || A0:F3:C1:76:4F:20 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=860 AHKRockenbrunner2] || C0:4A:00:0B:A8:94 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=856 AHKRockenbrunner3] || C4:6E:1F:F5:F4:AC || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1861 AHKRockenbrunner4] || 30:B5:C2:81:08:DA || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1650 OBT1] || 14cc2030e9ce || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1651 OBT2] || 14CC2030EA0C || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1659 OBT3] || 30B5C2D9B4AE || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1781 OBT4] || 30B5C2D9BD72 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1782 OBT5] || 30B5C2D9B522 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1842 ap1.refugees.kleinheubach] || 30:B5:C2:B0:56:0E || [https://netmon.freifunk-franken.de/user.php?user_id=446 oswald] || 30.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1847 stein-knauppstr-01] || C46E1F3B4262 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1845 stein-knauppstr-02] || E894F66D16A2 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1844 stein-knauppstr-03] || E894F6B981F6 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1848 stein-knauppstr-04] || 10FEEDCD9B3C || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1904 AsylcenterEbelsbach] || 30B5C2E301A6 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1319 AsylcenterEbelsbach1] || 30B5C2CB356C || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1591 refugees21.wue] || 68:72:51:2c:2f:9c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1602 refugees22.wue] || 12:bc:f9:69:d3:5c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1610 refugees23.wue] || 68:72:51:2c:30:bb || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2005 wue.N2N-ev.refugees.aux.001] || 60:e3:27:bd:ce:08 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2004 wue.N2N-ev.refugees.aux.002] || 60:e3:27:c7:30:3c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1819 wue.N2N-ev.refugees.aux.003] || 60:e3:27:c7:2f:d6 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2014 wue.N2N-ev.refugees.aux.004] || 14:cc:20:87:3c:5e || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2010 wue.N2N-ev.refugees.aux.005] || 60:e3:27:82:00:72 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2011 wue.N2N-ev.refugees.aux.006] || 60:e3:27:82:0a:3a || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2012 wue.N2N-ev.refugees.aux.007] || 68:72:51:2c:2c:28 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
| [https://netmon.freifunk-franken.de/router.php?router_id=2143 NotunterkunftGerbrunn0] || 30:B5:C2:3E:84:A2 || [https://netmon.freifunk-franken.de/user.php?user_id=630 dasaweb] || 17.01.2016 ||<br />
|}<br />
<br />
Mehr Infos über die Aux-Firmware [https://wiki.freifunk-franken.de/w/Was_ist_die_aux_Firmware hier.]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Liste_bekannter_Aux-FW_Router&diff=5331
Liste bekannter Aux-FW Router
2016-01-17T09:28:33Z
<p>Green: </p>
<hr />
<div>Um den Überblick über die mit Aux-FW geflashten Router zu behalten, wird eine Übersichtstabelle über die bekannten (d.h. zurückgemeldeten) Router geführt.<br />
<br />
{|<br />
! Routername !! Router-MAC !! gemeldet von !! gemeldet am !! Bemerkungen<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1317 Notunterkunft Turnhalle] || 14CC204D4786 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1318 Notunterkunft Turnhalle1] || 30B5C2AC26D8 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1355 ArnsteinerNetz0001] || 30:b5:c2:bd:77:ba || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1716 ArnsteinerNetz0002] || 30.b5:c2:bd:78:86 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1484 ArnsteinerNetz0005] || 30:b5:c2:88:47:14 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1754 ArnsteinerNetz0006] || 30:b5:c2:88:4e:00 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1248 ArnsteinerNetz002] || 30:b5:c2:d9:c8:ae || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1247 ArnsteinerNetz003] || 30:b5:c2:d9:c8:18 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1753 ArnsteinerNetz004] || 30:b5:c2:d9:c6:de || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || reiner AP, kein Mesh, Clientzählung durch Meshrouter "ArnsteinerNetz002" 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=583 WS13W01WR1043] || e8:de:27:fd:2b:aa || [https://netmon.freifunk-franken.de/user.php?user_id=6 delphiN] || 03.11.2015 || Beta 2 Testbetrieb<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1768 HabuRef01] || 30B5C20E8AE0 || [https://netmon.freifunk-franken.de/user.php?user_id=438 DerMichy] || 15.11.2015 || Pending installation in Hammelburg, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1766 Tannenberg01] || 60:E3:27:2A:56:46 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1769 Tannenberg02] || 30:B5:C2:E2:FD:EE || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1770 Tannenberg03] || 60:E3:27:2A:58:E4 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2066 Tannenberg04] || 60:E3:27:59:E3:C8 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 05.01.2016 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1751 AHKRockenbrunner1] || A0:F3:C1:76:4F:20 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=860 AHKRockenbrunner2] || C0:4A:00:0B:A8:94 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=856 AHKRockenbrunner3] || C4:6E:1F:F5:F4:AC || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1861 AHKRockenbrunner4] || 30:B5:C2:81:08:DA || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1650 OBT1] || 14cc2030e9ce || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1651 OBT2] || 14CC2030EA0C || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1659 OBT3] || 30B5C2D9B4AE || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1781 OBT4] || 30B5C2D9BD72 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1782 OBT5] || 30B5C2D9B522 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1842 ap1.refugees.kleinheubach] || 30:B5:C2:B0:56:0E || [https://netmon.freifunk-franken.de/user.php?user_id=446 oswald] || 30.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1847 stein-knauppstr-01] || C46E1F3B4262 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1845 stein-knauppstr-02] || E894F66D16A2 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1844 stein-knauppstr-03] || E894F6B981F6 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1848 stein-knauppstr-04] || 10FEEDCD9B3C || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1904 AsylcenterEbelsbach] || 30B5C2E301A6 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1319 AsylcenterEbelsbach1] || 30B5C2CB356C || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1591 refugees21.wue] || 68:72:51:2c:2f:9c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1602 refugees22.wue] || 12:bc:f9:69:d3:5c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1610 refugees23.wue] || 68:72:51:2c:30:bb || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2005 wue.N2N-ev.refugees.aux.001] || 60:e3:27:bd:ce:08 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2004 wue.N2N-ev.refugees.aux.002] || 60:e3:27:c7:30:3c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1819 wue.N2N-ev.refugees.aux.003] || 60:e3:27:c7:2f:d6 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2014 wue.N2N-ev.refugees.aux.004] || 14:cc:20:87:3c:5e || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2010 wue.N2N-ev.refugees.aux.005] || 60:e3:27:82:00:72 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2011 wue.N2N-ev.refugees.aux.006] || 60:e3:27:82:0a:3a || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2012 wue.N2N-ev.refugees.aux.007] || 68:72:51:2c:2c:28 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
| NotunterkunftGerbrunn0 || 30:B5:C2:3E:84:A2 || Weber || 17.01.2016 ||<br />
|}<br />
<br />
Mehr Infos über die Aux-Firmware [https://wiki.freifunk-franken.de/w/Was_ist_die_aux_Firmware hier.]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Liste_bekannter_Aux-FW_Router&diff=5269
Liste bekannter Aux-FW Router
2016-01-05T10:50:40Z
<p>Green: </p>
<hr />
<div>Um den Überblick über die mit Aux-FW geflashten Router zu behalten, wird eine Übersichtstabelle über die bekannten (d.h. zurückgemeldeten) Router geführt.<br />
<br />
{|<br />
! Routername !! Router-MAC !! gemeldet von !! gemeldet am !! Bemerkungen<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1317 Notunterkunft Turnhalle] || 14CC204D4786 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1318 Notunterkunft Turnhalle1] || 30B5C2AC26D8 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1355 ArnsteinerNetz0001] || 30:b5:c2:bd:77:ba || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1716 ArnsteinerNetz0002] || 30.b5:c2:bd:78:86 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1484 ArnsteinerNetz0005] || 30:b5:c2:88:47:14 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1754 ArnsteinerNetz0006] || 30:b5:c2:88:4e:00 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1248 ArnsteinerNetz002] || 30:b5:c2:d9:c8:ae || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1247 ArnsteinerNetz003] || 30:b5:c2:d9:c8:18 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1753 ArnsteinerNetz004] || 30:b5:c2:d9:c6:de || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || reiner AP, kein Mesh, Clientzählung durch Meshrouter "ArnsteinerNetz002" 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=583 WS13W01WR1043] || e8:de:27:fd:2b:aa || [https://netmon.freifunk-franken.de/user.php?user_id=6 delphiN] || 03.11.2015 || Beta 2 Testbetrieb<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1768 HabuRef01] || 30B5C20E8AE0 || [https://netmon.freifunk-franken.de/user.php?user_id=438 DerMichy] || 15.11.2015 || Pending installation in Hammelburg, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1766 Tannenberg01] || 60:E3:27:2A:56:46 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1769 Tannenberg02] || 30:B5:C2:E2:FD:EE || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1770 Tannenberg03] || 60:E3:27:2A:58:E4 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2066 Tannenberg04] || 60:E3:27:59:E3:C8 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 05.01.2016 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1751 AHKRockenbrunner1] || A0:F3:C1:76:4F:20 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=860 AHKRockenbrunner2] || C0:4A:00:0B:A8:94 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=856 AHKRockenbrunner3] || C4:6E:1F:F5:F4:AC || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1861 AHKRockenbrunner4] || 30:B5:C2:81:08:DA || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1650 OBT1] || 14cc2030e9ce || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1651 OBT2] || 14CC2030EA0C || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1659 OBT3] || 30B5C2D9B4AE || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1781 OBT4] || 30B5C2D9BD72 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1782 OBT5] || 30B5C2D9B522 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1842 ap1.refugees.kleinheubach] || 30:B5:C2:B0:56:0E || [https://netmon.freifunk-franken.de/user.php?user_id=446 oswald] || 30.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1847 stein-knauppstr-01] || C46E1F3B4262 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1845 stein-knauppstr-02] || E894F66D16A2 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1844 stein-knauppstr-03] || E894F6B981F6 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1848 stein-knauppstr-04] || 10FEEDCD9B3C || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1904 AsylcenterEbelsbach] || 30B5C2E301A6 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1319 AsylcenterEbelsbach1] || 30B5C2CB356C || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1591 refugees21.wue] || 68:72:51:2c:2f:9c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1602 refugees22.wue] || 12:bc:f9:69:d3:5c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1610 refugees23.wue] || 68:72:51:2c:30:bb || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2005 wue.N2N-ev.refugees.aux.001] || 60:e3:27:bd:ce:08 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2004 wue.N2N-ev.refugees.aux.002] || 60:e3:27:c7:30:3c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1819 wue.N2N-ev.refugees.aux.003] || 60:e3:27:c7:2f:d6 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2014 wue.N2N-ev.refugees.aux.004] || 14:cc:20:87:3c:5e || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2010 wue.N2N-ev.refugees.aux.005] || 60:e3:27:82:00:72 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2011 wue.N2N-ev.refugees.aux.006] || 60:e3:27:82:0a:3a || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2012 wue.N2N-ev.refugees.aux.007] || 68:72:51:2c:2c:28 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|}<br />
<br />
Mehr Infos über die Aux-Firmware [https://wiki.freifunk-franken.de/w/Was_ist_die_aux_Firmware hier.]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Liste_bekannter_Aux-FW_Router&diff=5268
Liste bekannter Aux-FW Router
2016-01-05T10:50:01Z
<p>Green: </p>
<hr />
<div>Um den Überblick über die mit Aux-FW geflashten Router zu behalten, wird eine Übersichtstabelle über die bekannten (d.h. zurückgemeldeten) Router geführt.<br />
<br />
{|<br />
! Routername !! Router-MAC !! gemeldet von !! gemeldet am !! Bemerkungen<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1317 Notunterkunft Turnhalle] || 14CC204D4786 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1318 Notunterkunft Turnhalle1] || 30B5C2AC26D8 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1355 ArnsteinerNetz0001] || 30:b5:c2:bd:77:ba || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1716 ArnsteinerNetz0002] || 30.b5:c2:bd:78:86 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1484 ArnsteinerNetz0005] || 30:b5:c2:88:47:14 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1754 ArnsteinerNetz0006] || 30:b5:c2:88:4e:00 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1248 ArnsteinerNetz002] || 30:b5:c2:d9:c8:ae || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1247 ArnsteinerNetz003] || 30:b5:c2:d9:c8:18 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1753 ArnsteinerNetz004] || 30:b5:c2:d9:c6:de || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || reiner AP, kein Mesh, Clientzählung durch Meshrouter "ArnsteinerNetz002" 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=583 WS13W01WR1043] || e8:de:27:fd:2b:aa || [https://netmon.freifunk-franken.de/user.php?user_id=6 delphiN] || 03.11.2015 || Beta 2 Testbetrieb<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1768 HabuRef01] || 30B5C20E8AE0 || [https://netmon.freifunk-franken.de/user.php?user_id=438 DerMichy] || 15.11.2015 || Pending installation in Hammelburg, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1766 Tannenberg01] || 60:E3:27:2A:56:46 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1769 Tannenberg02] || 30:B5:C2:E2:FD:EE || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1770 Tannenberg03] || 60:E3:27:2A:58:E4 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2066 Tannenberg04] || 60:E3:27:59:E3:C8 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 5.1.2016 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1751 AHKRockenbrunner1] || A0:F3:C1:76:4F:20 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=860 AHKRockenbrunner2] || C0:4A:00:0B:A8:94 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=856 AHKRockenbrunner3] || C4:6E:1F:F5:F4:AC || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1861 AHKRockenbrunner4] || 30:B5:C2:81:08:DA || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1650 OBT1] || 14cc2030e9ce || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1651 OBT2] || 14CC2030EA0C || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1659 OBT3] || 30B5C2D9B4AE || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1781 OBT4] || 30B5C2D9BD72 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1782 OBT5] || 30B5C2D9B522 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1842 ap1.refugees.kleinheubach] || 30:B5:C2:B0:56:0E || [https://netmon.freifunk-franken.de/user.php?user_id=446 oswald] || 30.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1847 stein-knauppstr-01] || C46E1F3B4262 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1845 stein-knauppstr-02] || E894F66D16A2 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1844 stein-knauppstr-03] || E894F6B981F6 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1848 stein-knauppstr-04] || 10FEEDCD9B3C || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1904 AsylcenterEbelsbach] || 30B5C2E301A6 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1319 AsylcenterEbelsbach1] || 30B5C2CB356C || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1591 refugees21.wue] || 68:72:51:2c:2f:9c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1602 refugees22.wue] || 12:bc:f9:69:d3:5c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1610 refugees23.wue] || 68:72:51:2c:30:bb || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2005 wue.N2N-ev.refugees.aux.001] || 60:e3:27:bd:ce:08 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2004 wue.N2N-ev.refugees.aux.002] || 60:e3:27:c7:30:3c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1819 wue.N2N-ev.refugees.aux.003] || 60:e3:27:c7:2f:d6 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2014 wue.N2N-ev.refugees.aux.004] || 14:cc:20:87:3c:5e || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2010 wue.N2N-ev.refugees.aux.005] || 60:e3:27:82:00:72 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2011 wue.N2N-ev.refugees.aux.006] || 60:e3:27:82:0a:3a || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2012 wue.N2N-ev.refugees.aux.007] || 68:72:51:2c:2c:28 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|}<br />
<br />
Mehr Infos über die Aux-Firmware [https://wiki.freifunk-franken.de/w/Was_ist_die_aux_Firmware hier.]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Server/fff-fra1&diff=5257
Server/fff-fra1
2016-01-02T18:59:39Z
<p>Green: /* Status */</p>
<hr />
<div>__NOTOC__<br />
<br />
= Gateway Server fff-fra1 =<br />
<br />
'''<font style="color:green">Status: online</font>'''<br />
<br />
== Status ==<br />
<br />
Zur Nachvollziebarkeit der Server-Einrichtung wird in ein [[Server/fff-fra1/Log|detailiertes Log]] geführt.<br />
<br />
* 25.09.15: Anfrage nach Untersützung für Flüchtlingsunterkünfte über [https://twitter.com/FreifunkFranken/status/647319580168310784 Twitter]<br />
* 25.09.15: Angebot von dotManged für einen Server mit bis zu 50 TB/Monat Traffic kostenlos.<br />
* 07.10.15: Vertrag ist vom Förderverein unterschrieben und wurde von delphiN an dotManaged weitergeleitet.<br />
* 08.10.15: delphiN hat Zugangsdaten bekommen (Passwörter geändert)<br />
* 09.10.15: Grundeinrichtung des Systems.<br />
* 11.10.15: Plaungstreffen und einrichtung als Layers2-Gateway.<br />
* 13.10.15: Testweise an Nürnberger Hood angeschlossen um zu testen.<br />
* 17.10.15: ca. 17 Uhr Speedtest<br />
* 18.10.15: ca. 18 Uhr Ein erster unbekannter Knoten geht ans Netz.<br />
* 22.10.15: Umstellung des IP-Bereichs<br />
* 24.10.15: RAM-Menge wurde vom Hoster gefixt (jetzt sind es 4 GB)<br />
* 22.12.15: November 2015: ca. 10TB pro Monat<br />
* 31.12.15: Ende Dez'15: ca. 1 TB am Tag, Tendenz steigend<br />
<br />
== Monitoring ==<br />
* http://fff-fra1.fff.community/<br />
** [https://www.dotmanaged.eu/rechenzentrum/weathermap/ Network-Weathermap dotManaged]<br />
** [http://84.200.64.42 Übersicht]<br />
** [http://84.200.64.42:8080/ OLSR Status]<br />
** [http://84.200.64.42:8083/ Realtime Server Monitor]<br />
<br />
== Ansprechpartner ==<br />
* '''Allgemein Fragen''': fragen ET freifunk-franken.de<br />
* '''Abuse''': abuse ET freifunk-franken.de<br />
* '''Admins''':<br />
** [[Benutzer:delphiN|delphiN]] (Admin-C)<br />
** [[Benutzer:mifritscher|mifritscher]] (Tech-C)<br />
** [[Benutzer:green|green]] (Monitoring, Wartung, usw.)<br />
** [[Benutzer:ChristianD|ChristianD]] (Monitoring, Wartung, usw.)<br />
** [http://wiki.freifunk.net/Benutzer:DanielP DanielP] (Admin vom Foerderverein Freie Netzwerke e.V.)<br />
* '''Sonstige User''':<br />
** [[Benutzer:ChristopherMaeuer|ChristopherMaeuer]] (Ansprechpartner bei dotmanaged)<br />
<br />
== Details ==<br />
<br />
* '''Type''': KVM Server<br />
* '''Verwendungszweck''': Internet-Gateway Server<br />
* '''Provider''': [https://www.dotmanaged.eu/ dotManaged]<br />
* '''Standort''': Frankfurt [https://www.accelerated.de/de/rechenzentrum]<br />
* '''Eigentümer''': Freie Netze e.V.<br />
* '''Kosten''': Spende von dotManaged gegen Spendenquittung<br />
<br />
* '''Technische Daten''':<br />
** IP-Bereich:<br />
*** 84.200.64.42 (84.200.64.40/29)<br />
** OS: Debian GNU/Linux 8.2 (jessie)<br />
** CPU: 4 x Intel Xeon E312xx (Sandy Bridge) 2.5GHz; vCore<br />
** RAM: 4 GB DDR3-1333 MHz ECC Registered<br />
** HDD: 10 GB HDD Raid-10 w/ 4x 2 TB Western Digital SE<br />
** NIC: VirtIO zu Intel NIC mit maximal 1 GBit/s<br />
<br />
== RIPE Einträge ==<br />
<br />
<pre><br />
inetnum: 84.200.64.40 - 84.200.64.47<br />
netname: DE-FREIFUNK-FRANKEN-01<br />
descr: Foerderverein Freie Netzwerke e.V.<br />
country: DE<br />
admin-c: AW5350-RIPE<br />
tech-c: TG5171-RIPE<br />
org: ORG-FFNE2-RIPE<br />
status: ASSIGNED PA<br />
mnt-by: MNT-WEESLY<br />
created: 2015-10-05T09:17:16Z<br />
last-modified: 2015-10-09T17:01:10Z<br />
source: RIPE<br />
</pre><br />
<br />
=== [https://apps.db.ripe.net/search/lookup.html?source=ripe&key=AR33715-RIPE&type=role ORGANISATION] ===<br />
<pre><br />
organisation: ORG-FFNE2-RIPE<br />
org-name: Foerderverein Freie Netzwerke e.V.<br />
org-type: OTHER<br />
address: Foerderverein Freie Netzwerke e.V.<br />
address: Freifunk Franken<br />
address: c/o Rabener - Rau<br />
address: Stephanstr. 10<br />
address: D-10559 Berlin<br />
abuse-c: AR33715-RIPE<br />
mnt-ref: MNT-WEESLY<br />
mnt-by: MNT-WEESLY<br />
created: 2015-10-05T09:12:49Z<br />
last-modified: 2015-10-07T19:24:32Z<br />
source: RIPE # Filtered<br />
</pre><br />
<br />
=== [https://apps.db.ripe.net/search/lookup.html?source=ripe&key=AW5350-RIPE&type=person ADMIN-C] === <br />
<pre><br />
person: Alexander Wunschik<br />
address: Foerderverein Freie Netzwerke e.V.<br />
address: Freifunk Franken<br />
address: c/o Rabener - Rau<br />
address: Stephanstr. 10<br />
address: D-10559 Berlin<br />
phone: +49 (911) 495205200<br />
abuse-mailbox: abuse@freifunk-franken.de<br />
nic-hdl: AW5350-RIPE<br />
mnt-by: MNT-WEESLY<br />
created: 2015-10-09T16:59:51Z<br />
last-modified: 2015-10-09T16:59:51Z<br />
source: RIPE # Filtered<br />
</pre><br />
<br />
=== [https://apps.db.ripe.net/search/lookup.html?source=ripe&key=TG5171-RIPE&type=person TECH-C] === <br />
<pre><br />
person: Michael Fritscher<br />
address: Foerderverein Freie Netzwerke e.V.<br />
address: Freifunk Franken<br />
address: c/o Rabener - Rau<br />
address: Stephanstr. 10<br />
address: D-10559 Berlin<br />
phone: +49 700 23023023<br />
abuse-mailbox: abuse@freifunk-franken.de<br />
nic-hdl: TG5171-RIPE<br />
mnt-by: MNT-WEESLY<br />
created: 2015-10-09T17:00:49Z<br />
last-modified: 2015-10-09T17:00:49Z<br />
source: RIPE # Filtered<br />
</pre><br />
<br />
[[Kategorie:Technik]]<br />
[[Kategorie:Server]]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Freifunk-Gateway_aufsetzen&diff=5256
Freifunk-Gateway aufsetzen
2016-01-02T18:32:54Z
<p>Green: /* DHCP Server */</p>
<hr />
<div>__TOC__<br />
[[Kategorie:Technik]]<br />
<br />
= Preface =<br />
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").<br />
<br />
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.<br />
<br />
Für Rat und Tat empfiehlt sich die Freifunk Franken Development Mailingliste.<br />
<br><br />
= Vorraussetzungen =<br />
* ssh-Zugang zum Server<br />
* Root Zugriff auf den Server. Entweder man ist "root" (Annahme in diesem Artikel) oder man kann Befehle mit "root-Rechten" durch ein vorgesetztes "sudo" ausführen sowie die Möglichkeit auf dem Server Kernelmodule zu laden (kann nicht jeder VServer!) <br />
* Grundlegende Netzwerkkenntnisse<br />
** IPv4 und Netzmaske<br />
** Devices<br />
** Routing (Default Route, Interfaces, Routing-Table) <br />
* Kentnisse <br />
** im Umgang mit Texteditoren (der im Artikel verwendete Editor kann durch beliebig andere ersetzt werden, z.B. durch "nano")<br />
** im Umgang mit der Linux Shell (z.B. Kommandozeilenparameter, Shell-Scripte, Umleitungen)<br />
** in der (selbständigen Nach-)Installation von (fehlenden) Software-Paketen<br />
** im Kompilieren von Software-Quellen<br />
<br><br />
= Referenzen / Andere Freifunk HowTo's =<br />
* http://wiki.freifunk.net/Freifunk_Hamburg/Gateway <br />
* http://wiki.mag.lab.sh/wiki/Freifunk_Fulda/Gateway<br />
<br><br />
= Anforderungen an Gateways =<br />
Die Anforderungen an das Gateway sind an sich niedrig. Wichtig ist, dass die Möglichkeit besteht, eigene Kernel-Module zu laden und das monatliche Traffic-Kontingent nicht zu niedrig ist. Entsprechend sind OpenVZ, Linux-vServer und ähnliche Containerlösungen nicht geeignet.<br />
<br />
Hardware:<br />
* CPU: 1x (64Bit)<br />
* RAM: 256MB .. 1GB<br />
* HDD: > 5 GB<br />
* NIC: 1x<br />
<br />
Software:<br />
* Debian Jessie (8) 64Bit Kernel <br />
* fastd v17<br />
* openvpn<br />
* B.A.T.M.A.N. adv 2013.4.0<br />
* dhcpd<br />
* olsr<br />
* bind9<br />
<br />
Pauschal gibt es keine Mindestanforderungen für den Trafficverbrauch. Es kommt sehr darauf an, wo der Server eingesetzt wird. <br />
'''Momentan suchen wir aber vor allem Server mit einem kostenlosen Traffic von mindestens 10-20 TB/Monat.'''<br />
<br><br />
== Anonymisierung (Störerhaftung) ==<br />
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.<br />
<br />
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. <br />
<br />
Folgende VPN-Anbieter sind zu diesem Zeitpunkt jedoch empfehlenswert:<br />
<br />
* [https://mullvad.net/en/ Mullvad] (Schweden, Niederlande)<br />
** Bis zu drei gleichzeitige Verbindungen<br />
** Kann man anonym mit Bitcoin bezahlen<br />
** Serverauswahl über die ausgelieferte OpenVPN-Konfiguration<br />
*** Server in den Niederlanden sind abends oft stark ausgelastet<br />
**(Gute Erfahrungen in Lübeck)<br />
<br />
* [https://integrityvpn.com/ Integrity VPN] (Schweden, Port80)<br />
** 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.<br />
**Hat eine überaus seriöse Webseite und eine Ltd. erfunden.™<br />
**Hat schon mal was von IPv6 gehört. Nutzt es zurzeit jedoch nur für SEO.<br />
**Blockiert Port 25 derzeit nicht.<br />
**Ist ein ein neuer Anbieter, der _bisher_ unausgelastet wirkt.<br />
** sind derzeit noch nicht nicht overselled und haben ihren Krams scheinbar halbwegs sauber konfiguriert<br />
<br />
* [https://ipredator.se/ Ipredator] (Schweden, Niederlande, Deutschland)<br />
** (Glänzen nicht durch Kompetenz, da sie lange Zeit nur PPTP angeboten haben)<br />
** Mögen schnelle Reconnects nicht -> manchmal muss man OpenVPN ein paar Stunden deaktivieren, bevor es wieder funktioniert.<br />
** Möchten bald auch IPv6 anbieten.<br />
** Angeblich Reseller von relakks<br />
<br />
Ungetestet:<br />
* [https://www.anonine.com/en Anonine VPN] (Portlane)<br />
* [https://privacy.io/ privacy.io] (Portlane)<br />
* [http://prq.se/?p=tunnel&intl=1 prq.se] (Eigenes Netz, teuer)<br />
* [http://arethusa.su/vpn.html Arethusa VPN] (Loggen in Frankreich, andere Server angeblich nicht)<br />
<br />
Einige Freifunknetze mieten auch VMs in Osteuropa. Da die VMs noch nicht an ihre Grezen stößt könnte man diese auch mitnutzen. Ansprechpartner wäre s0ma.<br />
<br><br />
== Anbindung an andere Netze ==<br />
Es gibt drei relativ relevante Netzwerke bei denen es sich lohnt, das lokale Netz damit zu verbinden:<br />
<br />
* InterCity-VPN zwischen den meisten Freifunknetzen<br />
** BGP<br />
** kleine Übsicht der http://www.ddmesh.de/topology/ic-vpn-verbindungen.html<br />
** Mehr Infos http://wiki.freifunk.net/IC-VPN<br />
<br />
* DN42<br />
** BGP<br />
** Experimentelles Darknet zur Erprobung von Routing-Technologien und so weiter, wird privat betrieben. Viel interessantes Zeugs™<br />
** 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.<br />
<br />
* ChaosVPN<br />
** Tinc<br />
** Relativ großes „Darknet“ zwischen vielen Hackerspaces auf der ganzen Welt.<br />
<br><br />
== vServer-Anbieter die empfehlenswert sind ==<br />
* [https://www.de-punkt.de/vserver.html de-punkt] (Databurg, FFM)<br />
** Schneller Speicher, gut bezahlbar, KVM, nur Traffic-Flat™® das übliche.<br />
* [http://www.hetzner.de/hosting/produktmatrix_vserver/vserver-produktmatrix Hetzner] (Falkenstein)<br />
** Bezahlbar, 6.90€/TB Extratraffic, KVM<br />
** Achtung: Die Netzwerkarte der VM ist aus Kompatibilitätsgründen auf e1000 gesetzt. Diese "Netzwerkkarte" kommt nicht mit den vielen UDP-Paketen von fastd zurecht. Deshalb muss man vor Verwendung als Gateway die Netzwerkkarte auf "virtio" stellen.<br />
* [http://colorhost.de/server/vserver/ colorhost] (über 23media, Global Switch, FFM)<br />
* Untersagt Nutzung für Freifunk (http://colorhost.de/server/vserver/kvm/small/)<br />
** Achtung: Nur Xen oder Xen HVM funktionieren<br />
* [http://www.xirra.net/en/v-server/productmatrix/ xirra] (Core-Backbone, NBG)<br />
** KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.<br />
* [http://buyvm.net/ BuyVM]<br />
** 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.<br />
* [http://webhod.de webhod]<br />
** 9,99 € für die kleinste KVM im Monat[https://www.webhod.de/de/vserver/kvm.html]<br />
<br><br />
== Server-Anbieter die '''nicht''' empfehlenswert sind ==<br />
* [http://www.wrzhost.com/ WRZhost]<br />
** 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.<br />
<br />
* [https://www.netcup.de/ netcup]<br />
** V-Server laufen zwar grundsätzlich gut, allerdings halten sie sich nicht an ihre Versprechungen. Server wurde bereits mehrfach gedrosselt obwohl der Traffic weit unter den versprochenen 80 Mbit/s war (zwischen 30 und 40 Mbit/s). Die Drosselung tritt ohne Vorwarnung in Kraft und man kann seinen Server nicht mehr erreichen. Entdrosselung nur auf Nachfrage und dann auch nur mit einigem hin und her.<br />
<br><br />
= Grundinstallation des Servers =<br />
Vom ausgesuchten Hoster lassen wir uns eine aktuelle Linux-Distribution installieren oder ausliefern, wobei sich die Anleitung auf ein Debian 8 / Jessie bezieht.<br />
<br><br />
== Repositories und Update ==<br />
Als erstes werfen wir einen Blick in...<br />
<br />
<code><br />
vi /etc/apt/sources.list<br />
</code><br />
<br />
...und schauen, inwieweit auf die gleichen Software-Repositories verwiesen wird:<br />
<br />
<pre> <br />
deb http://security.debian.org/ jessie/updates main<br />
deb-src http://security.debian.org/ jessie/updates main<br />
<br />
deb http://ftp.de.debian.org/debian/ jessie main contrib non-free<br />
deb-src http://ftp.de.debian.org/debian/ jessie main contrib non-free<br />
<br />
deb http://ftp.de.debian.org/debian/ jessie-updates main<br />
deb-src http://ftp.de.debian.org/debian/ jessie-updates main<br />
<br />
</pre><br />
<br />
Danach bringen wir das System auf einen aktuellen Stand:<br />
<br />
<code><br />
apt-get update<br />
<br />
apt-get upgrade<br />
</code><br />
<br><br />
== Sicherheit ==<br />
Den SSH-Zugang besser schützen durch:<br />
* Änderung des Ports<br />
* login nur mit key<br />
* Siehe [http://www.thomas-krenn.com/de/wiki/Absicherung_eines_Debian_Servers hier] für genaue Anleitung: <br />
<br />
<code><br />
apt-get install fail2ban<br />
</code><br />
<br />
und [http://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban_absichern einrichten]<br />
<br />
So,nun sollte der Server ausreichend abgesichert sein.<br />
<br><br />
== B.A.T.M.A.N. adv 2013.4.0 Kernel-Modul ==<br />
Batman-Adv aus Jessie ist zu neu. Hier muss manuell das alte B.A.T.M.A.N. advanced 2013.4.0 gebaut werden.<br />
<br />
Hierfür benötigen wir minimal die Paketquellen build-essential, linux-headers-amd64 und git:<br />
<br />
<code><br />
apt-get install build-essential linux-headers-amd64 git gnupg-curl<br />
</code><br />
<br />
Die Softwarequellen müssen heruntergeladen...<br />
<code><br />
cd ~<br />
<br />
git clone https://github.com/freifunk-gluon/batman-adv-legacy<br />
<br />
cd batman-adv-legacy<br />
</code><br />
<br />
... und kompiliert und installiert werden:<br />
<br />
<code><br />
make<br />
<br />
make install<br />
</code><br />
<br />
Hinweis: Sollten noch Paketquellen fehlen, wird dies während des Kompilierens gemeldet. Die Software-Quellen müssen nachinstalliert werden und der letzte Kompilierungs- und Installationsschritt so lange wiederholt werden, bis die Software erfolgreich erstellt wurde.<br />
<br />
Nach erfolgreicher Erstellung kann das B.A.T.M.A.N Kernel Modul per modprobe händisch eingebunden werden:<br />
<br />
<code><br />
modprobe batman-adv<br />
</code><br />
<br />
Es sollte dann im Kernel-log ....<br />
<code><br />
dmesg | grep batman_adv<br />
</code><br />
<br />
... mit einem Eintrag gelistet werden:<br />
<pre><br />
batman_adv: B.A.T.M.A.N. advanced 2013.4.0-21-ga854277-dirty (compatibility version 14) loaded<br />
</pre><br />
<br />
Das Kernelmodul von B.A.T.M.A.N. kann dann bei jedem Neustart des Systems geladen werden, indem in die Datei /etc/modules:<br />
<br />
<code><br />
vi /etc/modules<br />
</code><br />
<br />
..der Eintrag "batman-adv" hinzugefügt wird:<br />
<br />
<pre><br />
batman-adv<br />
</pre><br />
<br><br />
== B.A.T.M.A.N adv 2013.4.0 batctl ==<br />
Gleiches gilt für batctl, ein Kommandozeilenprogramm zur B.A.T.M.A.N Konfiguration. Die alte Version 2013.4.0 muss selber gebaut werden, da die Debian 8 / Jessie Paketquellen zu neu sind.<br />
<br />
Herunterladen und Entpacken der Softwarequellen:<br />
<code><br />
cd ~<br />
<br />
wget http://downloads.open-mesh.org/batman/releases/batman-adv-2013.4.0/batctl-2013.4.0.tar.gz<br />
<br />
tar xzf batctl-2013.4.0.tar.gz<br />
<br />
cd batctl-2013.4.0<br />
</code><br />
<br />
Kompilieren und Installieren:<br />
<br />
<code><br />
make<br />
<br />
make install<br />
</code><br />
<br />
Hinweis: Auch hier müssen ggf. fehlende Quellen händisch nachinstalliert und das Kompilieren und Installieren bis zum Erfolg wiederholt werden.<br />
<br><br />
== FastD ==<br />
Die Verbindung zwischen Gateway und Router wird über einen fastd-Tunnel realisiert.<br />
<br />
Hierfür müssen wir ein neues Repository in der Datei /etc/apt/sources.list deklarieren:<br />
<br />
<code><br />
vi /etc/apt/sources.list.d/universe-factory.list<br />
</code><br />
<br />
Dort fügen wir folgendes Repository an:<br />
<br />
<pre><br />
deb http://repo.universe-factory.net/debian/ sid main<br />
deb-src http://repo.universe-factory.net/debian/ sid main<br />
</pre><br />
<br />
Danach die PGP Schlüssel holen:<br />
<code><br />
gpg --keyserver hkps://hkpspool.sks-keyservers.net --recv-key 16EF3F64CB201D9C<br />
<br />
gpg -a --export 16EF3F64CB201D9C | apt-key add -<br />
</code><br />
<br />
Datenbankupdate der Paketverwaltung:<br />
<code><br />
apt-get update<br />
</code><br />
<br />
Installation von fastd: <br />
<code><br />
apt-get install fastd <br />
</code><br />
<br><br />
== OpenVPN ==<br />
OpenVPN (falls benötigt) installieren wir mit:<br />
<code><br />
apt-get install openvpn<br />
</code><br />
<br><br />
== DHCP ==<br />
Den DHCP Server installieren wir mit:<br />
<code><br />
apt-get install isc-dhcp-server <br />
</code><br />
<br><br />
== Bind9 ==<br />
Als DNS Server nehmen wir hier den de-facto-Standard bind:<br />
<code><br />
apt-get install bind9 <br />
</code><br />
<br><br />
== OLSR ==<br />
Als Routing-Protokoll, um die einzelnen Hoods später zu einem Freifunk-Franken weit kommunizierenden Netz zu verbinden, wird OLSR installiert:<br />
<br />
<code><br />
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd_0.6.8.1-1_amd64.deb<br />
<br />
dpkg -i olsrd_0.6.8.1-1_amd64.deb<br />
<br />
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd-plugins_0.6.8.1-1_amd64.deb<br />
<br />
dpkg -i olsrd-plugins_0.6.8.1-1_amd64.deb<br />
<br />
</code><br />
<br><br />
= Konfigurieren des Freifunk-Gateways =<br />
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 />
<br><br />
== IPv4 des Gateways, IP-Bereich der Hood und DHCP Range des Gateway==<br />
Für das Gateway suchen wir uns unter [[Portal:Netz]] eine IPv4 Adresse aus dem statischen Range der Hood aus. Für Fürth läuft der Bereich für die statischen Adressen z.B. von 10.50.32.1 - 10.50.32.255. Hiervon suchen wir uns eine '''freie''' Adresse aus, und reservieren diese, indem wir sie weiter unten in die Tabelle der statischen IPs eintragen.<br />
<br />
Die Fürther Hood hat den IP-Bereich 10.50.32.0-10.50.32.255. Als Netzwerk wird dieser Bereich mit 10.50.32.0/21 deklariert, d.h. die ersten 21 Bit der IP identifizieren das Netzwerk "Fürther Hood" und die restlichen 11 Bit stehen zur IP Vergabe zur Verfügung, wobei Anfang (10.50.32.0) und Ende des Bereiches (10.50.39.255) reserviert sind und nicht, weder statisch noch dynamisch durch DHCP, belegt werden dürfen. Eine alternative Schreibweise zu 10.50.32.0/21 ist das Double "Network 10.50.32.0" und "Netmask 255.255.248.0". Ein entsprechender IP-Rechner zur analogen Anwendung in anderen Hoods findet sich z.B. [http://www.heise.de/netze/tools/netzwerkrechner/ hier].<br />
<br />
Ebenso sollte man einen DHCP-Bereich innerhalb des IP-Bereichs der jeweiligen Hood, die der GW bedienen soll, reservieren (d.h. in die oberer Tabelle unter [[Portal:Netz]] eintragen). Jeder DHCP-Server vergibt dynamisch IPv4 Adressen an Clients aus einem vorher definierten Adressbereich. Dieser Adressbereich sollte sich:<br />
* innerhalb des IP-Range der Hood bewegen<br />
* sich nicht mit dem Adressbereich überschneiden, den andere DHCP Server in der Hood verwalten<br />
* sich nicht mit dem Bereich der statischen Adressen der Hood überschneiden<br />
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. Vom gesamten IP-Bereich der Fürther Hood vergibt z.B. das Gateway fff-nue1 die Teilmenge 10.50.35.0 - 10.50.36.255 an Clients und teilt ihnen auf dem Weg auch gleich mit, wie sie Domain-Namen in IPs auflösen und auf welchem Weg sie ins Internet oder in andere Hoods kommen.<br />
<br><br />
== Routing Tabelle für Freifunk ==<br />
Fürs Routing im Freifunk Franken Netz wird eine eigene Routing Tabelle namens "fff" deklariert.<br />
<br />
Dies geschieht indem man in der Datei /etc/iproute2/rt_tables ...<br />
<code><br />
vi /etc/iproute2/rt_tables<br />
</code><br />
<br />
... folgendes am Ende einfügt:<br />
<br />
<pre><br />
10 fff<br />
</pre><br />
<br />
Unsere Freifunk Routing Tabelle lässt sich später durch<br />
<code><br />
ip route show table fff<br />
</code><br />
anzeigen, sobald wir die Tabelle mit Einträgen füllen.<br />
<br><br />
== B.A.T.M.A.N Netzwerk-Interface, fff Routingregeln und -tabelle ==<br />
'''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.<br />
<br />
In der Datei /etc/network/interfaces ...<br />
<br />
<code><br />
vi /etc/network/interfaces<br />
</code><br />
<br />
fügen wir zunächst folgenden Textblock des Gateways "klee" aus der Fürther Hood an:<br />
<br />
<pre><br />
.<br />
.<br />
.<br />
# device: bat0<br />
iface bat0 inet manual<br />
post-up ifconfig $IFACE up<br />
##Einschalten post-up:<br />
# IP des Gateways am B.A.T.M.A.N interface:<br />
post-up ip addr add 10.50.32.5/21 dev $IFACE<br />
# Regeln, wann die fff Routing-Tabelle benutzt werden soll: <br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.0.0.0/8 table fff <br />
post-up ip rule add to 10.0.0.0/8 table fff<br />
# Route in die Fuerther Hood: <br />
post-up ip route add 10.50.32.0/21 dev $IFACE table fff<br />
# Start des DHCP Servers:<br />
post-up invoke-rc.d isc-dhcp-server restart<br />
<br />
##Ausschalten post-down:<br />
# Loeschen von oben definieren Routen, Regeln und Interface: <br />
post-down ip route del 10.50.32.0/21 dev $IFACE table fff<br />
post-down ip rule del from 10.0.0.0/8 table fff<br />
post-down ip rule del to 10.0.0.0/8 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ifconfig $IFACE down<br />
<br />
# VPN Verbindung in die Fuerther Hood<br />
iface ffffuerthVPN inet manual<br />
post-up batctl -m bat0 if add $IFACE<br />
post-up ifconfig $IFACE up<br />
post-up ifup bat0<br />
post-down ifdown bat0<br />
post-down ifconfig $IFACE down<br />
</pre><br />
<br />
In diesem Beispiel sind:<br />
* IP des Gateway/Netzmaske der Fürther Hood: 10.50.32.5/21<br />
* IP des Netzwerks Fürther Hood / Netzmaske der Fürther Hood: 10.50.32.0/21.<br />
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.<br />
<br />
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.).<br />
<br />
Die Regeln definieren, das Traffic der<br />
* aus dem Netzwerk 10.0.0.0/8 kommt<br />
* das Netzwerk 10.0.0.0/8 zum Ziel hat<br />
* oder über die B.A.T.M.A.N Schnittstelle übermittelt wird<br />
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.<br />
<br />
Im post-down Abschnitt werden die vorher definierten Regeln, Interfaces und Routen wieder gelöscht.<br />
<br />
Der untere Abschnitt definiert einen VPN Tunnel in die Fürther Hood. Der Name des Interfaces im Beispiel (ffffuerthVPN) kann individuell neu vergeben werden.<br />
<br><br />
== FastD Start- und Verwaltungsscript ==<br />
Für die Konfiguration von fastd importieren wir eine Datei in ''/etc/fastd'' mit dem Befehl:<br />
<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/fff_beispiel_fastd.sh -P /etc/fastd/<br />
</code><br />
<br />
Alternativ kann das Skript aus einer leeren Datei erstellt werden:<br />
<code><br />
touch /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
danach öffnen wir diese:<br />
<br />
<code><br />
vi /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
und editieren das Skript oder fügen ein Neues ein:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
SERVERNAME="beispiel"<br />
<br />
hood="hoodeintragen"<br />
project="fff"<br />
port=10004<br />
<br />
SERVERNAME="$SERVERNAME.$hood"<br />
<br />
hostname=$SERVERNAME<br />
<br />
if [ ! -d /etc/fastd ]<br />
then<br />
mkdir /etc/fastd<br />
fi<br />
<br />
if [ ! -d /etc/fastd/$project.$hood ]<br />
then<br />
mkdir /etc/fastd/$project.$hood<br />
mkdir /etc/fastd/$project.$hood/peers<br />
<br />
#fastd config<br />
(<br />
echo "# Log warnings and errors to stderr"<br />
echo "log level error;"<br />
echo "# Log everything to a log file"<br />
echo "log to syslog as \"${project}${hood}\" level info;"<br />
echo "# Set the interface name"<br />
echo "interface \"${project}${hood}VPN\";"<br />
echo "# Support xsalsa20 and aes128 encryption methods, prefer xsalsa20"<br />
echo "#method \"xsalsa20-poly1305\";"<br />
echo "#method \"aes128-gcm\";"<br />
echo "method \"null\";"<br />
echo "# Bind to a fixed port, IPv4 only"<br />
echo "bind any:${port};"<br />
echo "# Secret key generated by \"fastd --generate-key\""<br />
echo "secret \"$(fastd --generate-key | grep -i Secret | awk '{print $2}')\";" <br />
echo "# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)" <br />
echo "# (see MTU selection documentation)" <br />
echo "mtu 1426;" <br />
echo "on up \"/etc/fastd/${project}.${hood}/up.sh\";" <br />
echo "on post-down \"/etc/fastd/${project}.${hood}/down.sh\";" <br />
echo "# Include peers from the directory 'peers'" <br />
echo "include peers from \"/etc/fastd/${project}.${hood}/peers\";" <br />
echo "secure handshakes no;"<br />
) >> "/etc/fastd/$project.$hood/$project.$hood.conf"<br />
<br />
#fastd-up<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifdown \$INTERFACE"<br />
) >> /etc/fastd/$project.$hood/down.sh<br />
<br />
chmod +x /etc/fastd/$project.$hood/down.sh<br />
<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifup \$INTERFACE" >> /etc/fastd/$project.$hood/up.sh<br />
) >> /etc/fastd/$project.$hood/up.sh<br />
chmod +x /etc/fastd/$project.$hood/up.sh<br />
fi<br />
<br />
pubkey=$(fastd -c /etc/fastd/$project.$hood/$project.$hood.conf --show-key --machine-readable)<br />
port=$(grep ^bind /etc/fastd/$project.$hood/$project.$hood.conf | cut -d: -f2 | cut -d\; -f1)<br />
<br />
# fire up<br />
if [ "$(/sbin/ifconfig -a | grep -i ethernet | grep ${project}${hood}VPN)" = "" ]<br />
then<br />
/bin/rm /var/run/fastd.$project.$hood.pid<br />
fastd -c /etc/fastd/$project.$hood/$project.$hood.conf -d --pid-file /var/run/fastd.$project.$hood.pid<br />
fi<br />
<br />
# register<br />
wget -T15 -q "http://keyserver.freifunk-franken.de/${project}/?name=$hostname&port=$port&key=$pubkey" -O /tmp/fastd_${project}.${hood}_output <br />
if [ "$?" != "0" ]<br />
then<br />
echo "Update failed"<br />
echo "Exiting, no clean up, no refresh"<br />
exit<br />
fi<br />
<br />
touch /tmp/fastd_${project}.${hood}_starting<br />
<br />
filenames=$(cat /tmp/fastd_${project}.${hood}_output| grep ^#### | sed -e 's/^####//' | sed -e 's/.conf//g')<br />
for file in $filenames<br />
do<br />
grep -A100 ^####$file.conf$ /tmp/fastd_${project}.${hood}_output | grep -v ^####$file.conf$ | grep -m1 ^### -B100 | grep -v ^### | sed 's/ float;/;/g' > "/etc/fastd/$project.$hood/peers/$file"<br />
echo 'float yes;' >> "/etc/fastd/$project.$hood/peers/$file"<br />
done<br />
<br />
#find old peers<br />
OLD=$(find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print)<br />
<br />
if [ -n "${OLD}" ] ; then<br />
echo "Lösche alte:"<br />
echo $OLD<br />
<br />
find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print | xargs /bin/rm /tmp/fastd_${project}.${hood}_starting<br />
fi<br />
<br />
#reload<br />
kill -HUP "$(cat /var/run/fastd.$project.$hood.pid)"<br />
<br />
exit 0<br />
</pre><br />
<br />
Zum Schluss geben wir noch ein<br />
<br />
<code><br />
chmod +x /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
ein, um das Skript ausführbar zu machen.<br />
<br />
Das Skript konfiguriert fastd, indem es<br />
* einen Schlüssel generiert, sollte keiner existieren<br />
* diesen Schlüssel mit dem Keyserver austauscht<br />
* die fastd Konfigurationsdatei anlegt<br />
* den fastd Dämonen startet<br />
<br />
Lediglich der Servername und die Hood müssen oben im Skript händisch angepasst werden. Der Dateiname des Skripts kann individuell angepasst werden.<br />
<br />
Nachdem das Script ausgeführt wurde, sollte man überprüfen ob das Interface in der Konfigurationsdatei unter /etc/fastd/fff.<Hoodname>/fff.<Hoodname>.conf das gleiche ist wie vorher in /etc/network/interfaces festgelegt. Wenn der Name nicht identisch ist (Groß-/Kleinschreibung), werden die Interfaces nicht starten.<br />
<br />
Hinweis: Das Gateway wird standardmässig in die Default-Hood eingebunden. Es wird hier lediglich ein Name für die Konfigurationsdatei und der Gateway Name definiert. Die Zuordnung des Gateways zu der Hood erfolgt später über den KeyXchange (siehe unten).<br />
<br><br />
== IP-Forwarding ==<br />
Um Anfragen, die das Gateway erreichen, weiterzuleiten, muss IP-Forwarding aktiviert werden. <br />
<br />
Manuell geht dies über:<br />
<code><br />
echo "1" > /proc/sys/net/ipv4/ip_forward<br />
<br />
echo "1" > /proc/sys/net/ipv6/conf/default/forwarding<br />
<br />
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding<br />
</code><br />
<br />
Dauerhaft lässt sich IP-Forwarding in /etc/sysctl.conf aktivieren:<br />
<code><br />
vi /etc/sysctl.conf<br />
</code><br />
<br />
.. um dort die Abschnitte einzukommentieren, die das Forwarding steuern:<br />
<pre><br />
.<br />
.<br />
.<br />
# Uncomment the next line to enable packet forwarding for IPv4<br />
net.ipv4.ip_forward=1<br />
<br />
# Uncomment the next line to enable packet forwarding for IPv6<br />
# Enabling this option disables Stateless Address Autoconfiguration<br />
# based on Router Advertisements for this host<br />
net.ipv6.conf.all.forwarding=1<br />
.<br />
.<br />
.<br />
</pre><br />
<br><br />
== Testen von B.A.T.M.A.N, fastd und Autostart ==<br />
Hierfür booten wir das Gateway am besten erst mal neu:<br />
<code><br />
reboot & exit<br />
</code><br />
<br />
und starten das fast.d Startskript manuell: <br />
<code><br />
/etc/fastd/fff_beispiel_fastd.sh &<br />
</code><br />
<br />
Beim Erststart werden Schlüsselpaare generiert und ausgetauscht, es kann also etwas dauern.<br />
<br />
Danach sollte der Aufruf von...<br />
<code><br />
pgrep fastd<br />
</code><br />
... mit der Prozess-ID beantwortet werden: Fastd läuft in dem Fall.<br />
<br />
<br />
Ein Aufruf von ifconfig:<br />
<code><br />
ifconfig<br />
</code><br />
<br />
sollte die neu erstellten Interfaces bat0 und ffffuerthVPN zurückliefern.<br />
Exemplarisch und als Auszug:<br />
<pre><br />
bat0 Link encap:Ethernet HWaddr ea:95:50:07:f7:27 <br />
inet addr:10.50.32.5 Bcast:0.0.0.0 Mask:255.255.248.0<br />
inet6 addr: fe80::e895:50ff:fe07:f727/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:1089992 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:849698 errors:0 dropped:1728 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0 <br />
RX bytes:141311612 (134.7 MiB) TX bytes:1052934594 (1004.1 MiB)<br />
<br />
.<br />
.<br />
.<br />
ffffuerthVPN Link encap:Ethernet HWaddr e6:3b:f3:b7:fc:db <br />
inet6 addr: fe80::e43b:f3ff:feb7:fcdb/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1426 Metric:1<br />
RX packets:32389694 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:2699525 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:500 <br />
RX bytes:4193328694 (3.9 GiB) TX bytes:1384843740 (1.2 GiB)<br />
.<br />
.<br />
.<br />
</pre><br />
Aus dem ifconfig Auszug für bat0 sollte die eingerichtete IP des Gateways und die Netzmaske hervorgehen.<br />
<br />
<br />
Die Abfrage der IP-Regeln:<br />
<code><br />
ip rule<br />
</code><br />
<br />
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):<br />
<pre><br />
32757: from all to 10.0.0.0/8 lookup fff <br />
32758: from 10.0.0.0/8 lookup fff <br />
32759: from all iif bat0 lookup fff <br />
</pre><br />
<br />
Eine Abfrage der fff-Routing Tabelle<br />
<code><br />
ip route show table fff <br />
</code><br />
<br />
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:<br />
<pre><br />
10.50.32.0/21 dev bat0 scope link<br />
</pre><br />
<br />
Ein Aufruf von "batctl o"<br />
<code><br />
batctl o <br />
</code><br />
<br />
ergibt eine Liste der MAC-Adressen von unseren nächsten Nachbarn. Exemplarisch und als Auszug:<br />
<pre><br />
[B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: ffffuerthVPN/e6:3b:f3:b7:fc:db (bat0)]<br />
Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ...<br />
96:43:c4:2e:73:68 0.004s (255) 96:43:c4:2e:73:68 [ffffuerthVPN]: 96:43:c4:2e:73:68 (255)<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
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:<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
Hier spendieren wir einen Eintrag, der fastd mit 10 Sekunden Verzögerung bei jedem Systemstart mitstartet:<br />
<pre><br />
# launch fastd with 10 seconds delay<br />
(sleep 10; sh /etc/fastd/fff_beispiel_fastd.sh) &<br />
</pre><br />
<br />
'''Zusätzlich''' muss ein Cronjob angelegt werden, der das Skript z.B. alle 10 Minuten ausführt:<br />
<code><br />
crontab -e<br />
</code><br />
<br />
Nun folgendes eingeben:<br />
<pre><br />
*/10 * * * * sh /etc/fastd/fff_beispiel_fastd.sh<br />
</pre><br />
<br />
und<br />
<br />
<code><br />
/etc/init.d/cron restart<br />
</code><br />
<br><br />
== OpenVPN-Tunnel einrichten ==<br />
Die Einrichtung eines OpenVPN Tunnels kann von Anbieter zu Anbieter variieren. <br />
Im Laufe der Zeit sollte die Dokumentation so um funktionierende Konfigurationen verschiedener Anbieter erweitert werden.<br />
<br><br />
=== Mullvad ===<br />
Mullvad liefert in der Datei mullvadconfig.zip, die notwendigen Schlüssel (ca.crt, mullvad.crt, mullvad.key) als auch eine Konfigurationsdatei (mullvad_linux.conf) mit, die später angepasst werden muss.<br />
<br />
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:<br />
<br />
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.<br />
<br />
Als unverbindliche Richtschnur für Linux:<br />
<code><br />
scp mullvadconfig.zip root@<ipv4 des Gateways>:/root<br />
</code><br />
<br />
Danach loggen wir uns auf dem Gateway ein und entpacken die Datei (nicht vergessen unzip zu installieren):<br />
<code><br />
ssh root@<ipv4 des Gateways><br />
<br />
unzip mullvadconfig.zip<br />
<br />
cd <Kundennummernverzeichnis><br />
<br />
cp * /etc/openvpn<br />
</code><br />
<br />
''/etc/openvpn/'' sollte mit dem Inhalt des entpackten mullvadconfig.zip Archivs dann so aussehen:<br />
<pre><br />
ca.crt crl.pem mullvad.crt mullvad.key mullvad_linux.conf mullvad-up mullvad_windows.conf.ovpn <br />
</pre><br />
<br />
'''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.<br />
<br />
Wir legen ein benutzerspezifisches start-up Script namens mullvad-up an:<br />
<code><br />
vi /etc/openvpn/mullvad-up<br />
</code><br />
<br />
und füllen sie mit folgendem Inhalt:<br />
<pre><br />
#!/bin/bash<br />
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE<br />
</pre><br />
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.<br />
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.<br />
<br />
Das Skript mullvad-up muss ferner ausführbar sein:<br />
<code><br />
chmod +x /etc/openvpn/mullvad-up<br />
</code><br />
<br />
Dieses spezifische Routing muss zwingend in mullvad_linux.conf eingepflegt werden:<br />
<code><br />
vi /etc/openvpn/mullvad_linux.conf<br />
</code><br />
<br />
und hier die Konfiguration entsprechend geändert werden:<br />
<pre><br />
.<br />
.<br />
.<br />
# Allow calling of built-in executables and user-defined scripts.<br />
script-security 2<br />
<br />
# Parses DHCP options from openvpn to update resolv.conf<br />
#up /etc/openvpn/update-resolv-conf<br />
#down /etc/openvpn/update-resolv-conf<br />
<br />
# Enable Freifunk specific Routing<br />
route-noexec<br />
route-delay 3<br />
route-up /etc/openvpn/mullvad-up<br />
.<br />
.<br />
.<br />
</pre><br />
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.<br />
<br />
Wer möchte, kann in mullvad_linux.conf auch Länder definieren, über die der VPN Traffic laufen soll (Ein- /Auskommentieren).<br />
<br />
Der openvpn Tunnel kann nun testweise gestartet werden:<br />
<code><br />
cd /etc/openvpn<br />
<br />
/usr/sbin/openvpn mullvad_linux.conf &<br />
</code><br />
<br />
und sollte exemplarisch und im Auszug folgendes zurück liefern:<br />
<pre><br />
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<br />
Sun Sep 6 12:45:20 2015 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08<br />
Sun Sep 6 12:45:20 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts<br />
.<br />
.<br />
.<br />
Sun Sep 6 12:45:23 2015 /sbin/ip link set dev tun0 up mtu 1500<br />
Sun Sep 6 12:45:23 2015 /sbin/ip addr add dev tun0 10.114.0.45/16 broadcast 10.114.255.255<br />
Sun Sep 6 12:45:23 2015 /sbin/ip -6 addr add fdef:e287:a479:72::102b/112 dev tun0<br />
Sun Sep 6 12:45:23 2015 /etc/openvpn/mullvad-up tun0 1500 1558 10.114.0.45 255.255.0.0 init<br />
Sun Sep 6 12:45:23 2015 Initialization Sequence Completed<br />
</pre><br />
Wichtig ist hierbei, dass in der vorletztes Zeile unser Freifunk-spezifisches Routing durchgeführt wird.<br />
<br />
Das VPN-Gateway sollte nun als Default Route in der fff-Routingtabelle auftauchen:<br />
<code><br />
ip route show table fff | grep default<br />
</code><br />
<br />
Exemplarisch wäre eine Ausgabe für das Tunnel-Device tun0 und dem VPN-Gateway 10.114.0.1:<br />
<pre><br />
default via 10.114.0.1 dev tun0<br />
</pre><br />
<br />
Auch ein ifconfig Eintrag für das Tunnel Device...<br />
<code><br />
ifconfig<br />
</code><br />
<br />
...sollte jetzt existieren (Exemplarisch und im Auszug):<br />
<pre><br />
.<br />
.<br />
.<br />
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 <br />
inet addr:10.114.0.76 P-t-P:10.114.0.76 Mask:255.255.0.0<br />
inet6 addr: fdad:bdef:735d:72::104a/112 Scope:Global<br />
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1<br />
RX packets:1012476 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:640206 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:100 <br />
RX bytes:1250196616 (1.1 GiB) TX bytes:84979294 (81.0 MiB)<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
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:<br />
<code><br />
vi /etc/rc.local <br />
</code><br />
<br />
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:<br />
<pre><br />
# launch vpn with 5 seconds delay<br />
(sleep 5; /usr/sbin/openvpn /etc/openvpn/mullvad_linux.conf >> /var/log/mullvad_vpn.log &) &<br />
</pre><br />
<br><br />
<br />
=== NordVPN ===<br />
NordVPN liefert die Datei config.zip mit, die für jeden verwendbaren VPN-Server eine seperate Konfigurationsdatei enthält.<br />
<br />
'''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.<br />
<br />
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.<br />
<br />
Als unverbindliche Richtschnur für Linux:<br />
<code><br />
scp config.zip root@<ipv4 des Gateways>:/root<br />
</code><br />
<br />
Und entpacken diese auf dem Gateway:<br />
<code><br />
cd ~<br />
<br />
mkdir nordvpn-configs<br />
<br />
mv config.zip nordvpn-configs<br />
<br />
cd nordvpn-configs<br />
<br />
unzip config.zip<br />
</code><br />
<br />
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.<br />
<br />
Im Beispiel nehmen wir se1.nordvpn.com.udp1194.ovpn und passen Sie zunächst Freifunk-spezifisch an (siehe Aussperr-Hinweis oben):<br />
<br />
<code><br />
vi se1.nordvpn.com.udp1194.ovpn<br />
</code><br />
<br />
Ä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:<br />
<pre><br />
.<br />
.<br />
.<br />
# Provide Username and Password<br />
auth-user-pass /etc/openvpn/nordvpn-pw<br />
.<br />
.<br />
.<br />
# Allow calling of built-in executables and user-defined scripts.<br />
script-security 2<br />
<br />
# Enable Freifunk specific Routing<br />
route-noexec<br />
route-delay 3<br />
route-up /etc/openvpn/nordvpn-up<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
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:<br />
<code><br />
cp se1.nordvpn.com.udp1194.ovpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf<br />
</code><br />
<br />
Hier legen wir noch unser Freifunk Startskript und unsere Password Datei an und machen das Skript ausführbar:<br />
<code><br />
touch /etc/openvpn/nordvpn-up<br />
<br />
touch /etc/openvpn/nordvpn-pw<br />
<br />
chmod +x /etc/openvpn/nordvpn-up<br />
</code><br />
<br />
Man öffnet nordvpn-up...<br />
<code><br />
vi /etc/openvpn/nordvpn-up<br />
</code><br />
<br />
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):<br />
<pre><br />
#!/bin/bash<br />
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE<br />
</pre><br />
<br />
Nun öffnet man nordvpn-pw:<br />
<code><br />
vi /etc/openvpn/nordvpn-pw<br />
</code><br />
<br />
Und legt in der ersten Zeile der Datei seinen NordVPN Usernamen und in der zweiten Zeile sein NordVPN Passwort ab:<br />
<pre><br />
(Username bei NordVPN)<br />
(Password bei NordVPN)<br />
</pre><br />
<br />
Der Tunnel kann nun testweise gestartet werden (hier im Beispiel mit der Konfigurationsdatei se1.nordvpn.com.udp1194.ovpn)<br />
<code><br />
openvpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf &<br />
</code><br />
<br />
Und sollte aufgebaut werden:<br />
<pre><br />
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<br />
.<br />
.<br />
.<br />
Sun Sep 27 09:07:15 2015 /sbin/ip link set dev tun0 up mtu 1500<br />
Sun Sep 27 09:07:15 2015 /sbin/ip addr add dev tun0 local 10.8.8.226 peer 10.8.8.225<br />
Sun Sep 27 09:07:18 2015 Initialization Sequence Completed<br />
</pre><br />
<br />
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:<br />
<code><br />
vi /etc/rc.local <br />
</code><br />
<br />
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:<br />
<pre><br />
# launch vpn with 5 seconds delay<br />
(sleep 5; cd /etc/openvpn ; /usr/sbin/openvpn se1.nordvpn.com.udp1194.ovpn.conf >> /var/log/nordvpn.log &) &<br />
</pre><br />
Die Beispiel-Konfigurationsdatei (se1.nordvpn.com.udp1194.ovpn.conf) muss entsprechend angepasst werden.<br />
<br><br />
== DNS Server ==<br />
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.<br />
<br />
----<br />
<br />
'''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.'''<br />
<br />
----<br />
<br />
Hierfür editieren wir die Datei named.conf.options...<br />
<code><br />
vi /etc/bind/named.conf.options<br />
</code><br />
<br />
...und tragen die DNS Server, die wir anfragen wollen, wenn wir die Information nicht selber haben, als forwarders ein:<br />
<pre><br />
.<br />
.<br />
.<br />
forwarders {<br />
10.50.32.1;<br />
10.50.32.2;<br />
8.8.8.8;<br />
};<br />
allow-query { <br />
127.0.0.1/8; <br />
10.0.0.0/8; <br />
};<br />
.<br />
.<br />
. <br />
</pre><br />
In diesem Fall werden die Freifunk Gateways ro1 (10.50.32.1) und fff-nue1 (10.50.32.2) der Fürther Hood als auch Google DNS (8.8.8.8) als Forwarders definiert. Für andere Hoods muss die lokale Adresse der Freifunk DNS Server unter [[Portal:Netz]] ermittelt werden (z.B. 10.50.48.1 für ro1 in der Ansbacher Hood).<br />
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".<br />
<br />
Neustart des DNS-Servers mit der neuen Konfiguration:<br />
<code><br />
/etc/init.d/bind9 restart<br />
</code><br />
<br />
Testen können wir, indem wir vom DNS Server des Gateways (localhost/127.0.0.1) eine DNS-Auflösung abfragen. <br />
<br />
Ein DNS Resolve für freifunk-franken.de ...<br />
<code><br />
dig @127.0.0.1 freifunk-franken.de<br />
</code><br />
<br />
...sollte von uns selber (Server localhost; 127.0.0.1) beantwortet werden:<br />
<pre><br />
;; global options: +cmd<br />
<br />
;; Got answer:<br />
<br />
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5819<br />
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1 <br />
;; OPT PSEUDOSECTION:<br />
; EDNS: version: 0, flags:; udp: 4096<br />
<br />
;; QUESTION SECTION:<br />
;freifunk-franken.de. IN A<br />
;; ANSWER SECTION:<br />
freifunk-franken.de. 3599 IN A 31.172.113.113 <br />
.<br />
. <br />
.<br />
;; Query time: 117 msec<br />
;; SERVER: 127.0.0.1#53(127.0.0.1)<br />
;; WHEN: Tue Sep 08 14:16:32 EEST 2015<br />
;; MSG SIZE rcvd: 275<br />
</pre><br />
<br><br />
<br />
== B.A.T.M.A.N Gateway Selection ==<br />
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.<br />
<br />
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:<br />
* Bandbreite der Netzanbindung (z.B. 100 Mbit/sec, gesplittet in 50 Mbit/sec up/down)<br />
* 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)<br />
* Erfahrungswerten / eigenes Ermessen<br />
* Bandbreite, bei dem der Gateway Prozessor ausgelastet ist<br />
<br />
Eventuell muss zuerst bc nachinstalliert werden, falls nicht vorhanden:<br />
<code><br />
apt-get install bc<br />
</code><br />
<br />
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.<br />
<br />
Importieren des Skripts aus einer Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/dyn_announce_gw_bw.sh -P /usr/local/bin/<br />
</code><br />
<br />
Alternativ kann das Skript auch als leere Datei erstellt werden:<br />
<code><br />
touch /usr/local/bin/dyn_announce_gw_bw.sh<br />
</code><br />
<br />
Wir machen das Skript ausführbar und öffnen die Datei:<br />
<code><br />
chmod +x /usr/local/bin/dyn_announce_gw_bw.sh<br />
<br />
vi /usr/local/bin/dyn_announce_gw_bw.sh<br />
</code><br />
<br />
Und Füllen dieses mit Inhalt oder editieren den importierten Inhalt:<br />
<pre><br />
#!/bin/bash<br />
<br />
<br />
if [ -z "$1" ]; then<br />
echo<br />
echo "usage: $0 <network-interface> <update_interval [sec]> <total BW up [Mbit/sec]> <total BW down [Mbit/sec]>"<br />
echo<br />
echo "e.g. $0 eth0 60 10 10"<br />
echo<br />
exit<br />
fi<br />
<br />
while true<br />
do<br />
# Bandwidth currently used (time averaged)<br />
R1=$(cat "/sys/class/net/$1/statistics/rx_bytes")<br />
T1=$(cat "/sys/class/net/$1/statistics/tx_bytes")<br />
sleep "$2"<br />
R2=$(cat "/sys/class/net/$1/statistics/rx_bytes")<br />
T2=$(cat "/sys/class/net/$1/statistics/tx_bytes")<br />
TkbitPS=$(echo "scale=0; ($T2 - $T1) / 1024 * 8 / $2" | bc -l)<br />
RkbitPS=$(echo "scale=0; ($R2 - $R1) / 1024 * 8 / $2" | bc -l)<br />
# echo "BW used -- up $1: $TkbitPS kBit/s; down $1: $RkbitPS kBit/s"<br />
<br />
# Remaining bandwidth available; cut-off negative values<br />
Tavail_kbitPS=$(echo "scale=0; if (($3 * 1024 - $TkbitPS) >0) ($3 * 1024 - $TkbitPS) else 0" | bc -l)<br />
Ravail_kbitPS=$(echo "scale=0; if (($4 * 1024 - $RkbitPS) >0) ($4 * 1024 - $RkbitPS) else 0" | bc -l)<br />
# echo "BW available -- up $1: $Tavail_kbitPS kBit/s; down $1: $Ravail_kbitPS kBit/s"<br />
<br />
# Pass calculated figures to B.A.T.M.A.N Gateway Selection<br />
for bat in /sys/class/net/bat*; do<br />
iface=${bat##*/}<br />
batctl -m $iface gw_mode server "${Ravail_kbitPS}kbit/${Tavail_kbitPS}kbit" <br />
done<br />
<br />
done<br />
</pre><br />
<br />
Das Skript übernimmt als Parameter:<br />
* Netzwerkinterface, das es zu überwachen gilt (i.d.R. eth0)<br />
* 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)<br />
* Upload Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)<br />
* Download Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)<br />
<br />
Ein Aufruf für eth0 als Interface, ein Update alle 120 Sekunden, 12 Mbit/sec maximaler Upload und 10 Mbit/sec maximaler Download wäre z.B.:<br />
<code><br />
/usr/local/bin/dyn_announce_gw_bw.sh eth0 120 12 10<br />
</code><br />
<br />
Um die Gateway Selection beim Systemsstart zu aktivieren, können wir das Skript z.B. in rc.local aufrufen:<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
um dort, leicht zeitverzögert, o.a. Befehl einzupflegen, wobei die Parametrisierung noch Gateway-spezifisch angepasst werden muss:<br />
<pre><br />
.<br />
.<br />
.<br />
#enable batman GW selection with 15 seconds delay<br />
(sleep 15; /usr/local/bin/dyn_announce_gw_bw.sh eth0 120 12 10) &<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
ACHTUNG! Bei mehreren bat Interfaces (weil man in mehreren Hoods Gateway ist) muss diese Einstellung für jedes Gateway gesetzt werden, hier muss das Script unbedingt überarbeitet werden!<br />
<br />
<pre><br />
batctl -m $batX gw_mode xxmbit/xxmbit<br />
</pre><br />
<br />
und dies für jedes batX Interface. Das Script muss daraufhin noch angepasst werden.<br />
<br />
<br />
auf den Routern kann der vorselektierte Gateway mit <br />
<br />
<code><br />
batctl gwl<br />
</code><br />
<br />
angeguckt werden. Ich vermute das der Gateway mit den Pfeil vorne der vorselektierte Gateway ist, allerdings machen erste beobachtete Daten bisher in meinen Augen noch keinen wirklichen Sinn.<br />
<br><br />
<br />
== DHCP Server ==<br />
Die DHCP Konfiguration kann schon mal vorbereitet werden, sollte aber erst mit als letzter Schritt scharf geschaltet werden. Ein DHCP-Server, der Clients nicht funktionierende DNS-Server oder ein nicht funktionierendes Gateway mitteilt, sperrt diese aus dem Freifunk Netz aus.<br />
<br />
In isc-dhcp-server definieren wir ...<br />
<code><br />
vi /etc/default/isc-dhcp-server<br />
</code><br />
<br />
... das der DHCP Server für das B.A.T.M.A.N Device Anfragen beantworten soll:<br />
<pre><br />
.<br />
.<br />
<br />
INTERFACES="bat0"<br />
.<br />
.<br />
</pre><br />
<br />
Nachfolge Konfiguration wird in auskommentierter Form vorbereitet und sollte erst im letzten Schritt durch Einkommentieren und durch einen Neustart des DHCP Servers...<br />
<code><br />
/etc/init.d/isc-dhcp-server restart<br />
</code><br />
...aktiviert werden.<br />
<br />
Die Konfiguration wird in dhcpd.conf vorgenommen:<br />
<code><br />
vi /etc/dhcp/dhcpd.conf<br />
</code><br />
<br />
und folgender Konfigurationsblock zunächst auskommentiert eingefügt, wobei Gateway und Hood spezifische Änderungen noch eingepflegt werden müssen:<br />
<pre><br />
.<br />
.<br />
.<br />
### Freifunk Franken<br />
#option domain-name "fff.community";<br />
#option domain-name-servers 10.50.16.1;<br />
#authoritative;<br />
### Fuerth<br />
#subnet 10.50.32.0 netmask 255.255.248.0 { # Netzwerk und Netzmaske der Fuerther Hood<br />
# range 10.50.38.0 10.50.39.254; # IP-Range die der DHCP-Server innerhalb der Fuerther Hood verwaltet <br />
# option routers 10.50.32.5; # Default-Gateway, dass Clients mitgeteilt wird <br />
# option domain-name-servers 10.50.32.5, 10.50.32.1; # Name-Server, die Clients mitgeteilt werden<br />
#}<br />
</pre><br />
<br />
Netzwerk und Netzmaske müssen derjenigen der Hood des Gateways entsprechen. Im Beispiel ist dies Fürth, für z.B. Hassberge hieße der Eintrag "subnet 10.50.56.0 netmask 255.255.252.0".<br />
<br />
Der IP-Bereich (Range), die der DHCP-Server in der Hood verwaltet, wurde zuvor unter [[Portal:Netz]] reserviert.<br />
<br />
Unter Routers wird den Clients das Default-Gateway mitgeteilt: Das Gateway, über das Clients das Internet oder eine andere Hood erreichen. In unserem Beispiel routet das aufgesetzte Gateway selber via VPN ins Internet oder via olsr (später) in andere Hoods. Als Default-Gateway wird also die eigene statische IP des Gateways, aus der eigenen Hood, die in [[Portal:Netz]] reserviert wurde, verwendet.<br />
<br />
Ähnlich verhält es sich mit den Nameservern: Auf unserem Gateway wurde ein DNS Server eingerichtet, also kann der domain-name-server unser eigenes Gateway, mit der reservierten statische IP aus der Hood, wie in [[Portal:Netz]], sein. Als Backup empfiehlt sich ein weiterer DNS-Server aus der Hood, in unserem Beispiel ro1 in der Fürther.<br />
<br><br />
<br />
== GRE-Tunnel zu anderen Gateways ==<br />
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]].<br />
<br />
Der GRE-Tunnel wird in /etc/network/interfaces...<br />
<code><br />
vi /etc/network/interfaces<br />
</code><br />
<br />
...mit folgenden noch auf das Gateway anzupassenden Einträgen deklariert:<br />
<pre><br />
auto <tunnel><br />
iface <tunnel> inet static<br />
address <Eigene IPv4 (Freifunk Netz)><br />
pre-up ip -4 tunnel add $IFACE mode gre local <Eigene IPv4 (Internet)> remote <IPv4 des Tunnelpartners (Internet)> ttl 255<br />
#pre-up ip -6 tunnel add $IFACE mode ip6gre local <Eigene IPv6 (Internet)> remote <IPv6 des Tunnelpartners (Internet)> ttl 255<br />
<br />
up ifconfig $IFACE multicast<br />
pointopoint <IPv4 des Tunnelpartners (Freifunk Netz)><br />
post-up iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu<br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.50.0.0/16 table fff<br />
post-up ip rule add to 10.50.0.0/16 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ip rule del from 10.50.0.0/16 table fff<br />
post-down ip rule del to 10.50.0.0/16 table fff<br />
post-down iptables -t mangle -D POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu<br />
post-down iptunnel del $IFACE<br />
</pre><br />
<br />
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.<br />
<br />
'''Beispiel:''' <br />
Um als fff-nue1 einen Tunnel zu ro1 aufzubauen, können die IP-Adressen wie folgt gewählt werden:<br />
<pre><br />
<tunnel> ro1<br />
<Eigene IPv4 (Freifunk Netz)> fff-nue1 10.50.252.1<br />
<IPv4 des Tunnelpartners (Freifunk Netz)> ro1 10.50.252.0<br />
<Eigene IPv4 (Internet)> fff-nue1 31.172.33.99<br />
<IPv4 des Tunnelpartners (Internet)> ro1 176.126.221.7<br />
</pre><br />
<br />
In der Partnerkonfiguration für ro1 werden die Rollen entsprechend vertauscht:<br />
<pre><br />
<tunnel> fff-nue1<br />
<Eigene IPv4 (Freifunk Netz)> ro1 10.50.252.0<br />
<IPv4 des Tunnelpartners (Freifunk Netz)> fff-nue1 10.50.252.1<br />
<Eigene IPv4 (Internet)> ro1 176.126.221.7<br />
<IPv4 des Tunnelpartners (Internet)> fff-nue1 31.172.33.99 <br />
</pre><br />
<br />
Der Tunnel kann über den Aufruf von<br />
<code><br />
ifup <tunnel><br />
</code><br />
...aufgebaut werden, wobei <tunnel> der Name des GRE-Interfaces ist (im Beispiel ro1)<br />
<br />
Nach Aufruf von ifconfig..<br />
<code><br />
ifconfig <br />
</code><br />
sollten wir einen Eintrag für den Tunnel (in diesem Beispiel ro1) vorfinden:<br />
<pre><br />
.<br />
.<br />
.<br />
ro1 Link encap:UNSPEC HWaddr B0-7B-1C-73-30-30-3A-35-00-00-00-00-00-00-00-00 <br />
inet addr:10.50.252.1 P-t-P:10.50.252.0 Mask:255.255.255.255<br />
inet6 addr: fe80::200:5efe:b07b:1c73/64 Scope:Link<br />
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1476 Metric:1<br />
RX packets:160913 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:146654 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0 <br />
RX bytes:66984353 (63.8 MiB) TX bytes:10675001 (10.1 MiB)<br />
.<br />
.<br />
.<br />
</pre><br />
<br><br />
== OLSR ==<br />
=== Basiskonfiguration ===<br />
Mittels OLSR können die Gateways selbstständig Routinginformationen austauschen. Ähnlich wie B.A.T.M.A.N einzelne Router innerhalb einer Hood vermesht (Level 2 Netz), handelt es sich bei olsr um ein mesh zwischen den Gateways (Level 3). Es ermöglicht ein Freifunk Franken internes Routing: z.B. kann eine beliebige IPv4 aus der Nürnberger Hood aus der Fürth Hood heraus erreicht werden.<br />
<br />
Vorlagen können unter Sicherung der Originaldateien wie folgt importiert werden:<br />
<code><br />
mv /etc/default/olsrd /etc/default/olsrd.orig<br />
<br />
mv /etc/olsrd/olsrd.conf /etc/olsrd/olsrd.conf.orig<br />
<br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd -P /etc/default/<br />
<br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd.conf -P /etc/olsrd/<br />
</code><br />
<br />
Zunächst zeigen wir die Interfaces an, unter dem wir olsr Routing Informationen austauschen:<br />
<code><br />
vi /etc/default/olsrd<br />
</code><br />
<br />
Im Beispiel wird über die 2 GRE-Tunnel nue1 und ro1 ausgetauscht, dies muss entsprechend der GRE-Tunnel Konfiguration angepasst werden: <br />
<pre><br />
.<br />
.<br />
#<br />
# Uncomment the next line run olsrd automatically at startup<br />
#<br />
START_OLSRD="YES"<br />
<br />
#<br />
# Uncomment the next line to force-configure the wifi interface to be setup<br />
# for ad-hoc mode using the /usr/sbin/olsrd-adhoc-setup script whenever olsrd<br />
# is started.<br />
#<br />
SETUP_ADHOC="NO"<br />
.<br />
.<br />
.<br />
#<br />
# Specify the network interfaces that olsrd will run on, this will most likely<br />
# be your wifi interface.<br />
#<br />
MESH_IF="nue1 ro1" <br />
.<br />
.<br />
</pre><br />
<br />
<br />
Weiter wird dann hier ...<br />
<code><br />
vi /etc/olsrd/olsrd.conf<br />
</code><br />
... konfiguriert. <br />
Da unser Beispiel-Gateway ins Netz der Fürther Hood eingebunden ist, teilen wir dies andern Gateways über den Eintrag 10.50.32.0/21 mit:<br />
<pre><br />
.<br />
.<br />
.<br />
# HNA IPv4 routes<br />
# syntax: netaddr netmask<br />
# Example Internet gateway:<br />
# 0.0.0.0 0.0.0.0<br />
<br />
Hna4<br />
{<br />
# Internet gateway:<br />
# 0.0.0.0 0.0.0.0<br />
# more entries can be added:<br />
# 192.168.1.0 255.255.255.0<br />
10.50.32.0/21<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Hier wird das olsr Webinterface auf port 8080 konfiguriert:<br />
<br />
<pre><br />
.<br />
.<br />
.<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
# defaults to 1978<br />
PlParam "Port" "8080"<br />
# if you dont set these, the default is to listen only on the loopback device<br />
#PlParam "Host" "80.23.53.22"<br />
#PlParam "Net" "10.0.0.0 255.0.0.0"<br />
PlParam "Net" "0.0.0.0 0.0.0.0"<br />
#PlParam "Host" "127.0.0.1"<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Ferner wird der VPN-Tunnel (hier tun0) per persönlich angepasstem ping Kommando auf sein Funktion hin überwacht. Sollte der VPN-Tunnel ausfallen, ermöglicht olsr im Zusammenspiel mit der Routing Priorisierung (s.u) und der OpenVPN Start-/Stop Automatik (s.u.) ein automatisches Re-Routing:<br />
<pre><br />
.<br />
.<br />
.<br />
LoadPlugin "olsrd_dyn_gw.so.0.5"<br />
{<br />
# Here parameters are set to be sent to the<br />
# plugin. Theese are on the form "key" "value".<br />
# Parameters ofcause, differs from plugin to plugin.<br />
# Consult the documentation of your plugin for details.<br />
<br />
# Example: dyn_gw params<br />
<br />
# how often to check for Internet connectivity<br />
# defaults to 5 secs<br />
PlParam "Interval" "5"<br />
<br />
# if one or more IPv4 addresses are given, do a ping on these in<br />
# descending order to validate that there is not only an entry in<br />
# routing table, but also a real internet connection. If any of<br />
# these addresses could be pinged successfully, the test was<br />
# succesful, i.e. if the ping on the 1st address was successful,the<br />
# 2nd won't be pinged<br />
PlParam "Ping" "8.8.8.8"<br />
PlParam "Ping" "82.165.230.17"<br />
PlParam "pingcmd" "ping -c 1 -q -I tun0 %s"<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Folgender Konfigurationsblock muss ans Ende der Konfigurationsdatei angefügt werden. Es ermöglich olsr die Manipulation der fff-Routingtabelle:<br />
<pre><br />
.<br />
.<br />
.<br />
# Specify the proto tag to be used for routes olsr inserts into kernel<br />
# currently only implemented for linux<br />
# valid values under linux are 1 .. 254<br />
# 1 gets remapped by olsrd to 0 UNSPECIFIED (1 is reserved for ICMP redirects)<br />
# 2 KERNEL routes (not very wise to use)<br />
# 3 BOOT (should in fact not be used by routing daemons)<br />
# 4 STATIC<br />
# 8 .. 15 various routing daemons (gated, zebra, bird, & co)<br />
# (defaults to 0 which gets replaced by an OS-specific default value<br />
# under linux 3 (BOOT) (for backward compatibility)<br />
#<br />
RtProto 8<br />
#<br />
# Specifies the routing Table olsr uses<br />
# RtTable is for host routes, RtTableDefault for the route to the default<br />
# internet gateway (2 in case of IPv6+NIIT) and RtTableTunnel is for<br />
# routes to the ipip tunnels, valid values are 1 to 254<br />
# There is a special parameter "auto" (choose default below)<br />
# (with smartgw: default is 254/223/224)<br />
# (without smartgw: default is 254/254/254, linux main table)<br />
#<br />
RtTable 10<br />
RtTableDefault 10<br />
RtTableTunnel 10<br />
#<br />
# Specifies the policy rule priorities for the three routing tables and<br />
# a special rule for smartgateway routing (see README-Olsr-Extensions)<br />
# Priorities can only be set if three different routing tables are set.<br />
# if set the values must obey to condition<br />
# RtTablePriority < RtTableDefaultOlsrPriority<br />
# < RtTableTunnelPriority < RtTableDefaultPriority.<br />
# There are two special parameters, "auto" (choose fitting to SmartGW<br />
# mode) and "none" (do not set policy rule)<br />
# (with smartgw: default is none/32776/32776/32796)<br />
# (without smartgw: default is none/none/none/none)<br />
#<br />
# RtTablePriority auto<br />
# RtTableDefaultOlsrPriority auto<br />
# RtTableTunnelPriority auto<br />
# RtTableDefaultPriority auto<br />
</pre><br />
<br />
<br />
Das Freifunk Franken intere Routing kann nun getestet werden.<br />
<br />
Zunächst einmal starten wir olsr neu:<br />
<code><br />
/etc/init.d/olsrd restart<br />
</code><br />
<br />
<br />
Die Routinginformationen des olsr-meshes sollten in der fff-Routingtabelle auftauchen:<br />
<code><br />
ip route show table fff<br />
</code><br />
<br />
Exemplarischer Auszug:<br />
<pre><br />
.<br />
.<br />
.<br />
10.50.32.1 via 10.50.32.1 dev ro1 proto gated metric 2 onlink <br />
10.50.32.2 via 10.50.32.2 dev nue1 proto gated metric 2 onlink <br />
10.50.40.0/21 via 10.50.32.1 dev ro1 proto gated metric 2 onlink <br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Eine IP4 aus der Nürnberger Hood (10.50.40.0/21) sollte z.B. von Fürth aus (10.50.32.0/21) erreichbar sein:<br />
<br />
<code><br />
ping 10.50.40.3<br />
</code><br />
<br />
Antwort:<br />
<pre><br />
PING 10.50.40.3 (10.50.40.3) 56(84) bytes of data.<br />
64 bytes from 10.50.40.3: icmp_seq=1 ttl=63 time=42.2 ms<br />
64 bytes from 10.50.40.3: icmp_seq=2 ttl=63 time=42.7 ms<br />
^C<br />
--- 10.50.40.3 ping statistics ---<br />
2 packets transmitted, 2 received, 0% packet loss, time 1000ms<br />
rtt min/avg/max/mdev = 42.279/42.516/42.753/0.237 ms<br />
</pre><br />
<br><br />
=== OpenVPN Start/Stop Automatik ===<br />
OLSR testet mit dem Dynamic Gateway Plugin, ob die Default Route über den OpenVPN Tunnel noch funktioniert, indem regelmässig teilweise mehrere verschiedene Ziele über den Tunnel angepingt werden. Sollte der OpenVPN Tunnel nicht mehr funktionieren, baut OLSR eine neue Default-Route zu einem anderem Gateway auf, über das dann der Internet-Traffic läuft. Beide Default-Routen, die über den OpenVPN Tunnel und die von OLSR, existieren parallel, wobei zunächst weiterhin die OpenVPN Verbindung verwendet wird.<br />
<br />
Da die OpenVPN Verbindung ausgefallen ist, aber trotzdem noch als bevorzugte Default-Route eingetragen ist, ist die Internetanbindung bis die Störung VPN-Server seitig behoben ist, trotzdem nicht verfügbar. <br />
<br />
Für diesen Anwendungsfall wird ein Skript vorgeschlagen, dass die Funktion des OpenVPN Tunnels überwacht und den Tunnel (und die OpenVPN Default-Route) bei Nicht-Funktion abbaut. Um die Funktion zu überprüfen werden in regelmässigen Abständen 2 verschiedene Ziele über den Tunnel angepingt. Scheitert dies, wird der Tunnel für einen gewissen Zeitraum abgebaut, in dem dann stattdessen das OLSR Dynamic Gateway Plugin das Routing übernimmt. Danach wird die Verbindung wieder aufgebaut. Anschliessend wird überprüft, ob der OpenVPN-Tunnel wieder funktioniert. Tut er es nicht, wird er wieder abbgebaut, funktioniert er, bleibt er bis zur Detektion der nächsten Störung als Internetanbindung erhalten.<br />
<br />
Man importiert die Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/auto_start-stop_ovpn.sh -P /usr/local/bin/<br />
</code><br />
<br />
Alternativ kann man statt der Vorlage auch eine leere Datei anlegen:<br />
<code><br />
touch /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
Man macht das Skript ausführbar:<br />
<code><br />
chmod +x /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
<br />
Nun öffnet man die Datei im Editor ...<br />
<code><br />
vi /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
... und füllt sie mit Inhalt oder editiert den importierten Inhalt:<br />
<pre><br />
#!/bin/bash<br />
IF="tun0" # Interface used for ping<br />
ping1_target="8.8.8.8" # IP no. 1 used for ping<br />
ping2_target="82.165.229.31" # IP no. 2 used for ping<br />
ping_interval="5" # waiting time in-between two pings<br />
switchback_interval="3600" # waiting time for interface to recover before probing again<br />
start_grace="10" # waiting time to allow for tunnel restart<br />
logfile="/dev/null" # logfile for debug<br />
<br />
openvpn_stop-cmd () { # command used disabling tunnel<br />
#service openvpn stop # ubuntu<br />
/etc/init.d/openvpn stop # debian<br />
#killall openvpn # hardcore<br />
}<br />
<br />
openvpn_start-cmd () { # command used enabling tunnel<br />
#service openvpn start # ubuntu<br />
/etc/init.d/openvpn start # debian<br />
#openvpn /etc/openvpn/*.conf & # hardcore<br />
}<br />
<br />
ping1 () {<br />
echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF" &>> $logfile<br />
ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF &>> $logfile<br />
ping1_ExitCode=$?<br />
echo "$(date): Exit Status: ${ping1_ExitCode}" &>> $logfile<br />
}<br />
<br />
ping2 () {<br />
echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF" &>> $logfile<br />
ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF &>> $logfile<br />
ping2_ExitCode=$?<br />
echo "$(date): Exit Status: ${ping2_ExitCode}" &>> $logfile<br />
}<br />
<br />
<br />
while true<br />
do<br />
# wait for interface build-up, if interface not present<br />
if [ ! -h "/sys/class/net/$IF" ]; then<br />
echo "$(date): Interface $IF not detected. Waiting ${start_grace} seconds." &>> $logfile<br />
sleep ${start_grace}<br />
fi<br />
<br />
# perform ping<br />
ping1<br />
ping2<br />
<br />
# check if ping successful<br />
if ([[ ${ping1_ExitCode} -eq 0 ]] || [[ ${ping2_ExitCode} -eq 0 ]]); then<br />
sleep ${ping_interval}<br />
else<br />
logger -t "$0" ${ping1_target} and ${ping2_target} not reached via interface $IF.<br />
echo "$(date): ${ping1_target} and ${ping2_target} not reached via interface $IF." &>> $logfile<br />
<br />
if [ -h "/sys/class/net/$IF" ]; then<br />
logger -t "$0" Stopping interface $IF.<br />
echo "$(date): Stopping interface $IF." &>> $logfile<br />
openvpn_stop-cmd &>> $logfile<br />
fi<br />
<br />
sleep ${switchback_interval}<br />
<br />
if [ ! -h "/sys/class/net/$IF" ]; then<br />
logger -t "$0" Restoring interface $IF to probe for recovery.<br />
echo "$(date): Restoring interface $IF to probe for recovery." &>> $logfile<br />
openvpn_start-cmd &>> $logfile<br />
fi<br />
fi<br />
done<br />
</pre><br />
<br />
Hierbei können im Skript folgende Anpassungen vorgenommen werden:<br />
*openvpn_stop-cmd: Der Befehl, mit dem der OpenVPN Tunnel '''abgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ als Prozess gekillt werden.<br />
*openvpn_start-cmd: Der Befehl, mit dem der OpenVPN tunnel '''aufgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ per openvpn Kommandozeilenaufruf gestartet werden.<br />
*IF: Das OpenVPN Tunnel Device. Normalerweise ist das tun0.<br />
*ping1_target,ping2_target: Die IP-Adressen die über das Tunnel-Interface IF angepingt werden, um den Tunnel auf Funktion zu überprüfen. Vorauswahl: Google DNS und Web.de<br />
*ping_interval: Der zeitliche Anstand zwischen zwei Ping-Versuchen. Vorauswahl: 5 Sekunden.<br />
*switchback_interval: Der Zeitraum, den der Tunnel abgebaut bleibt, sollte er als nicht-funktionierend erkannt worden sein. Es wird ein träges Verhalten empfohlen. Vorauswahl: 3600 Sekunden.<br />
*start_grace: Der Zeitraum, der dem Tunnel zum Starten eingeräumt wird. Die Timer-Funktion macht ferner das Skript gegen Restarts des Tunnels unempfindlich.<br />
*logfile: Für Debug Zwecke kann man detaillierte Ausgaben hier in eine Datei umleiten.<br />
<br />
Das Skript selber kann manuell ...<br />
<code><br />
auto_start-stop_ovpn.sh &<br />
</code><br />
<br />
...und bei jedem Systemstart mit gestartet werden, indem es z.B. in /etc/rc.local ...<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
...wie folgt eingetragen wird:<br />
<pre><br />
.<br />
.<br />
.<br />
#enable tunnel monitoring with 60 seconds delay<br />
(sleep 60; auto_start-stop_ovpn.sh &) &<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Getestet werden kann das Skript z.B., indem man sich alle Default-Routen der fff-Tabelle anzeigen lässt: <br />
<code><br />
watch "ip route show table fff | grep default"<br />
</code><br />
<br />
und parallel dazu auf einer zweiten Shell das openvpn deaktiviert:<br />
<code><br />
killall openvpn<br />
</code><br />
<br />
Es sollte eine neue Default-Route zu einem anderen Gateway aufgebaut werden, über die der Internet-Traffic dann läuft. Die Route über den OpenVPN Tunnel sollte verschwinden. Nach der eingestellten Zeit wird der OpenVPN Tunnel durch das Skript wieder reaktiviert. Danach existieren beide Default-Routen parallel, bis OLSR seine Route automatisch wieder abbaut. Die OpenVPN Default-Route bleibt und ist wieder aktiv.<br />
<br><br />
=== Priorisieren von OLSR Routen ===<br />
OLSR erstellt die fff-Routingtabelle selbstständig, indem es die Linkqualität anhand von Algorithmen bewertet. Diese Bewertung ist recht volatil, was dazu führen kann, das die von OLSR ausgesuchte Default-Route häufig wechselt. Für die verbundenen Clients wechselt jedes mal die externe Internet IP mit, je nachdem über welches Gateway OLSR den Internet-Traffic gerade abwirft. Bei IP-Wechsel stoppen z.B. Downloads aus dem Internet, stoppen Videos im Abspielen, werden ssh Verbindungen gekappt.<br />
<br />
Um diese Dynamik nicht allzu schnell zu gestalten, empfiehlt es sich OLSR eine oder zwei Default-Routen mitzuteilen, die bevorzugt verwendet werden. Zusätzlich wird NatThreshold, einen Schwellwert den die neue Default-Route besser sein muss als die alte, bevor gewechselt wird, definiert.<br />
<br />
Dies geschieht über Gewichtungsfaktoren in olsrd.conf:<br />
<br />
<code><br />
vi /etc/olsrd/olsrd.conf<br />
</code><br />
<br />
Routen kann man im Abschnitt InterfaceDefaults priorisieren. <br />
Hier können Gewichtungsfaktoren für die GRE-Tunnel zu anderen Gateways eingeführt werden, mit denen die Link-Qualität beeinflusst werden kann:<br />
<pre><br />
.<br />
.<br />
.<br />
# If a certain route should be preferred<br />
# or ignored by the mesh, the Link Quality<br />
# value of a node can be multiplied with a factor<br />
# entered here. In the example the route<br />
# using 192.168.0.1 would rather be ignored.<br />
# A multiplier of 0.5 will result in a small<br />
# (bad) LinkQuality value and a high (bad)<br />
# ETX value.<br />
<br />
# preferred link<br />
LinkQualityMult <tunnel1_ip> 0.99<br />
<br />
# preferred link<br />
LinkQualityMult <tunnel2_ip> 0.99<br />
<br />
# This multiplier applies to all other nodes<br />
LinkQualityMult default 0.7<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Im Beispiel werden alle Routen herabgestuft (Faktor 0.7), mit der Ausnahme derer die über <tunnel1_ip> oder <tunnel2_ip> laufen (Faktor 0.99). <tunnel_ip1> sind dabei die Point-to-Point Partner IPs der GRE Tunnel der jeweiligen Gateways im Freifunk Netz. Die nicht herabgestuften Routen können analog als priorisiert betrachtet werden. Für eine Priorisierung der Route von nue1 zu ro1 wäre die <tunnel1/2_ip> z.B. die 10.50.252.1 (Vgl. [[Portal:Netz]]).<br />
<br />
NatThreshold wird im Hauptabschnitt von olsrd.conf definiert:<br />
<pre><br />
.<br />
.<br />
# If the NAT-Endpoint (the preferred 0/0 HNA emitting node)<br />
# is to be changed, the ETX value of the current 0/0 is<br />
# multiplied with the NatThreshold value before being<br />
# compared to the new one<br />
# The parameter can be a value between 0.1 and 1.0, but<br />
# should be close to 1.0 if changed.<br />
<br />
NatThreshold 0.7<br />
.<br />
.<br />
</pre><br />
<br />
Im Beispiel muss die Linkqualität der neuen Default-Route um 30% besser bewertet als die aktuelle sein, bevor die Default-Route gewechselt wird.<br />
<br />
Die Änderungen werden nach Neustart von OLSR aktiv:<br />
<code><br />
/etc/init.d/olsrd restart<br />
</code><br />
<br><br />
= Einbringen des Gateways in die Hood / Keyserver =<br />
Abschliessend muss das Gateway im Keyserver als Gateway der entsprechenden Hood eingetragen werden. Hierfür benötigt man einen Keyserver-Administrator => [[Server]].<br />
<br />
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.<br />
<br />
Der DHCP-Server sollte als letzter Schritt aktiviert werden (s.o.)<br />
<br><br />
= Transparent Proxy =<br />
Auf dem Gateway kann (aber muss nicht) ein Proxy-Server installiert werden, der Dateien (z.B. Bilder), die schon mal angefragt wurden, nicht aus dem Internet holt, sondern als "lokal" gespeicherte Datei direkt vom Gateway bereitstellt. Die Clients werden dabei über den Proxy gezwungen, d.h. das Gateway leitet die Anfragen pauschal an den Proxy weiter, welcher entscheidet ob der die Anfrage selber bedient oder Gateway-extern anfragt. <br />
<br />
Die Einrichtung eines Proxys ist '''optional''', d.h. der Proxy ist für die Funktion des Gateways nicht notwendig. Proxy-Server reduzieren Antwortzeiten und Traffic für sich '''häufig''' wiederholende Anfragen (z.B. Spiegel Online, Windows Update).<br />
<br />
'''Hinweis''': <br />
Die Einrichtung eines Proxy ist umstritten, da:<br />
* HTTP-Header, wenn auch in geringem Umfang, verändert werden<br />
* Daten, wenn auch nicht direkt einsehbar, auf dem Gateway gespeichert werden<br />
* Daten nicht unmittelbar von der Originalquelle bezogen werden <br />
* Die Effizienzsteigerung gering ist. Nach Auswertung werden ca. 7% aller unverschlüsselten HTTP-Anfragen von dem Gateway direkt beantwortet. Für diese 7% halbiert sich der benötigte Traffic, wobei ein Großteil aller Webseiten heutzutage verschlüsselt wird und z.Zt. 50% des benötigten Traffics Overhead ist. <br />
* Zusätzliche Ressourcen (RAM, Prozessor) auf dem Gateway benötigt werden <br />
<br />
'''Inkompatiblität''': Die Konfiguration funktioniert z.Zt. nicht im Zusammenspiel mit der "OpenVPN Start/Stop Automatik" und dem automatischen OLSR Re-Routing des Default-Gateways (Dynamic Gateway Plugin).<br />
<br><br />
== Installation ==<br />
Installiert wird der de-facto-Standard squid:<br />
<code><br />
apt-get install squid3<br />
</code><br />
<br />
Für die kommende Konfiguration stoppen wir squid wieder:<br />
<code><br />
/etc/init.d/squid3 stop<br />
</code><br />
<br><br />
== Konfiguration ==<br />
Die mit installiere Konfigurationsdatei squid.conf ist sehr umfangreich und bietet eine gute Dokumentationsbasis, ist damit aber auch etwas unhandlich.<br />
<br />
Aus diesem Grund empfiehlt es sich, die Datei umzubenennen:<br />
<code><br />
mv /etc/squid3/squid.conf /etc/squid3/squid.conf.orig<br />
</code><br />
<br />
Wir importieren die Datei von einer Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/squid.conf -P /etc/squid3/<br />
</code><br />
<br />
Alternativ können wir die Datei auch leer erstellen:<br />
<code><br />
touch /etc/squid3/squid.conf<br />
</code><br />
<br />
Danach öffnen wir die Konfigurationsdatei...<br />
<code><br />
vi /etc/squid3/squid.conf<br />
</code><br />
<br />
...und füllen diese mit Inhalt, der allerdings noch auf das Gateway angepasst werden muss:<br />
<pre> <br />
# cache size in MB / no. of subdirectories / no. of subsubdirectories<br />
cache_dir ufs /var/spool/squid3 100 16 256<br />
<br />
#maximum object size in cache (default: 4 MB)<br />
#maximum_object_size 128 MB<br />
maximum_object_size 4 MB<br />
<br />
# Memory used for caching<br />
cache_mem 32 MB<br />
<br />
# No access log<br />
#access_log /var/log/squid3/access.log combined<br />
access_log none<br />
<br />
# Hostname shown in messages<br />
visible_hostname fff<br />
<br />
# Bind Squid to port ... and configure as transparent proxy <br />
http_port 3128 intercept<br />
# In addition a forward proxy is required<br />
http_port 3129<br />
<br />
refresh_pattern ^ftp: 1440 20% 10080<br />
refresh_pattern ^gopher: 1440 0% 1440<br />
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0<br />
refresh_pattern . 0 20% 4320<br />
<br />
# Allow connects from Freifunk Franken network<br />
acl fff src 10.50.0.0/16 <br />
<br />
# DNS by Freifunk-IP of localhost and Google DNS<br />
dns_nameservers 10.50.32.5 8.8.8.8<br />
<br />
# Bind outgoing address to Freifunk-Server IP to allow for VPN Routing <br />
tcp_outgoing_address 10.50.32.5<br />
udp_outgoing_address 10.50.32.5<br />
<br />
# Privacy options <br />
via off<br />
forwarded_for delete<br />
<br />
# standard http anonymizer<br />
request_header_access From deny all<br />
#request_header_access Referer deny all<br />
#request_header_access User-Agent deny all<br />
<br />
## paranoid http anonymizer<br />
#request_header_access Authorization allow all<br />
#request_header_access Proxy-Authorization allow all<br />
#request_header_access Cache-Control allow all<br />
#request_header_access Content-Length allow all<br />
#request_header_access Content-Type allow all<br />
#request_header_access Date allow all<br />
#request_header_access Host allow all<br />
#request_header_access If-Modified-Since allow all<br />
#request_header_access Pragma allow all<br />
#request_header_access Accept allow all<br />
#request_header_access Accept-Charset allow all<br />
#request_header_access Accept-Encoding allow all<br />
#request_header_access Accept-Language allow all<br />
#request_header_access Connection allow all<br />
#request_header_access All deny all<br />
<br />
# Access controls<br />
acl SSL_ports port 443 # https<br />
acl Safe_ports port 80 # http<br />
acl Safe_ports port 21 # ftp<br />
acl Safe_ports port 443 # https<br />
acl Safe_ports port 70 # gopher<br />
acl Safe_ports port 210 # wais<br />
acl Safe_ports port 1025-65535 # unregistered ports<br />
acl Safe_ports port 280 # http-mgmt<br />
acl Safe_ports port 488 # gss-http<br />
acl Safe_ports port 591 # filemaker<br />
acl Safe_ports port 777 # multiling http<br />
<br />
acl CONNECT method CONNECT<br />
http_access deny !Safe_ports<br />
http_access deny CONNECT !SSL_ports<br />
http_access allow localhost manager<br />
http_access deny manager<br />
http_access allow fff<br />
http_access allow localhost<br />
http_access deny all<br />
</pre><br />
<br />
Hier '''müssen''' angepasst werden:<br />
* cache_dir: Die Gesamtgröße des Caches (hier: 100 MByte) muss so bemessen sein, dass auf der Partition auch bei Maximalgröße des Caches noch Speicher frei bleibt. Squid Standardeinstellung ist 100 MB bei 16 Verzeichnissen und jeweils 256 Unterverzeichnissen. Freier Speicherplatz kann mit "df -h" ermittelt werden.<br />
* dns_nameservers: Hier sollten die '''Freifunk-IPv4''' des Gateways (in diesem Beispiel 10.50.32.5) und eine externe IP (hier Google DNS 8.8.8.8) eingetragen werden. Wichtig ist, '''nicht localhost''' einzutragen, da die Anfrage im Zusammenspiel mit der "outgoing address" (s.u.) über die fff-Routingtabelle laufen muss.<br />
* tcp_outgoing_address und udp_outgoing_address: Diese beide Einträge sind elementar wichtig. Zwar funktioniert der Proxy auch ohne, routet aber nicht über das VPN sondern direkt vom Gateway ins Internet. Damit die fff-Routingtabelle verwendet wird, für die als Default-Gateway eine VPN Verbindung eingerichtet ist, tragen wir hier die Freifunk-IP des Gateways ein (10.50.<irgendwas>). In diesem Beispiel ist die Freifunk-IPv4 des Gateways die 10.50.32.5.<br />
* access_log: Das Access log sollte deaktiviert bleiben (access_log none), da es ein lebendiges Beispiel für Vorratsdatenspeicherung ist und die log-Dateien auch sehr schnell, sehr groß werden.<br />
<br />
Danach erstellen wir die Verzeichnisstruktur des Proxy:<br />
<code><br />
squid3 -z<br />
</code><br />
<br />
Jetzt sind wir fast fertig. Wir starten den Proxy:<br />
<code><br />
/etc/init.d/squid3 start<br />
</code><br />
<br />
Anfragen, die auf Port 80 (http) reinkommen, müssen nun noch auf Port 3128 umgeleitet werden. Auf Port 3128 lauscht unser Proxy, http-Anfragen werden quasi transparent (oder zwangsweise) über den Proxy geleitet :<br />
<code><br />
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
</code><br />
<br />
Damit unsere Portumleitung mit jedem Start von Squid eingerichtet und mit jedem Stopp aufgehoben wird, pflegen wir sie (nicht ganz sauber) im squid start/stop Skript mit ein:<br />
<code><br />
vi /etc/init.d/squid3<br />
</code><br />
<br />
und fügen '''zwei''' iptables Einträge nach dem Start und vor dem Stopp von Squid ein:<br />
<pre><br />
.<br />
.<br />
.<br />
start () {<br />
cache_dir=`find_cache_dir cache_dir`<br />
cache_type=`grepconf cache_dir`<br />
<br />
#<br />
# Create run dir (needed for several workers on SMP)<br />
#<br />
create_run_dir<br />
<br />
#<br />
# Create spool dirs if they don't exist.<br />
#<br />
if test -d "$cache_dir" -a ! -d "$cache_dir/00"<br />
then<br />
log_warning_msg "Creating $DESC cache structure"<br />
$DAEMON -z -f $CONFIG<br />
fi<br />
<br />
umask 027<br />
ulimit -n 65535<br />
cd $cache_dir<br />
start-stop-daemon --quiet --start \<br />
--pidfile $PIDFILE \<br />
--exec $DAEMON -- $SQUID_ARGS < /dev/null<br />
# Use as transparent proxy<br />
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
return $?<br />
}<br />
<br />
stop () {<br />
PID=`cat $PIDFILE 2>/dev/null`<br />
# Use as transparent proxy<br />
iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
start-stop-daemon --stop --quiet --pidfile $PIDFILE --exec $DAEMON <br />
#<br />
# Now we have to wait until squid has _really_ stopped.<br />
#<br />
.<br />
.<br />
.<br />
</pre></div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Freifunk-Gateway_aufsetzen&diff=5255
Freifunk-Gateway aufsetzen
2016-01-02T17:38:47Z
<p>Green: /* B.A.T.M.A.N Gateway Selection */</p>
<hr />
<div>__TOC__<br />
[[Kategorie:Technik]]<br />
<br />
= Preface =<br />
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").<br />
<br />
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.<br />
<br />
Für Rat und Tat empfiehlt sich die Freifunk Franken Development Mailingliste.<br />
<br><br />
= Vorraussetzungen =<br />
* ssh-Zugang zum Server<br />
* Root Zugriff auf den Server. Entweder man ist "root" (Annahme in diesem Artikel) oder man kann Befehle mit "root-Rechten" durch ein vorgesetztes "sudo" ausführen sowie die Möglichkeit auf dem Server Kernelmodule zu laden (kann nicht jeder VServer!) <br />
* Grundlegende Netzwerkkenntnisse<br />
** IPv4 und Netzmaske<br />
** Devices<br />
** Routing (Default Route, Interfaces, Routing-Table) <br />
* Kentnisse <br />
** im Umgang mit Texteditoren (der im Artikel verwendete Editor kann durch beliebig andere ersetzt werden, z.B. durch "nano")<br />
** im Umgang mit der Linux Shell (z.B. Kommandozeilenparameter, Shell-Scripte, Umleitungen)<br />
** in der (selbständigen Nach-)Installation von (fehlenden) Software-Paketen<br />
** im Kompilieren von Software-Quellen<br />
<br><br />
= Referenzen / Andere Freifunk HowTo's =<br />
* http://wiki.freifunk.net/Freifunk_Hamburg/Gateway <br />
* http://wiki.mag.lab.sh/wiki/Freifunk_Fulda/Gateway<br />
<br><br />
= Anforderungen an Gateways =<br />
Die Anforderungen an das Gateway sind an sich niedrig. Wichtig ist, dass die Möglichkeit besteht, eigene Kernel-Module zu laden und das monatliche Traffic-Kontingent nicht zu niedrig ist. Entsprechend sind OpenVZ, Linux-vServer und ähnliche Containerlösungen nicht geeignet.<br />
<br />
Hardware:<br />
* CPU: 1x (64Bit)<br />
* RAM: 256MB .. 1GB<br />
* HDD: > 5 GB<br />
* NIC: 1x<br />
<br />
Software:<br />
* Debian Jessie (8) 64Bit Kernel <br />
* fastd v17<br />
* openvpn<br />
* B.A.T.M.A.N. adv 2013.4.0<br />
* dhcpd<br />
* olsr<br />
* bind9<br />
<br />
Pauschal gibt es keine Mindestanforderungen für den Trafficverbrauch. Es kommt sehr darauf an, wo der Server eingesetzt wird. <br />
'''Momentan suchen wir aber vor allem Server mit einem kostenlosen Traffic von mindestens 10-20 TB/Monat.'''<br />
<br><br />
== Anonymisierung (Störerhaftung) ==<br />
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.<br />
<br />
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. <br />
<br />
Folgende VPN-Anbieter sind zu diesem Zeitpunkt jedoch empfehlenswert:<br />
<br />
* [https://mullvad.net/en/ Mullvad] (Schweden, Niederlande)<br />
** Bis zu drei gleichzeitige Verbindungen<br />
** Kann man anonym mit Bitcoin bezahlen<br />
** Serverauswahl über die ausgelieferte OpenVPN-Konfiguration<br />
*** Server in den Niederlanden sind abends oft stark ausgelastet<br />
**(Gute Erfahrungen in Lübeck)<br />
<br />
* [https://integrityvpn.com/ Integrity VPN] (Schweden, Port80)<br />
** 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.<br />
**Hat eine überaus seriöse Webseite und eine Ltd. erfunden.™<br />
**Hat schon mal was von IPv6 gehört. Nutzt es zurzeit jedoch nur für SEO.<br />
**Blockiert Port 25 derzeit nicht.<br />
**Ist ein ein neuer Anbieter, der _bisher_ unausgelastet wirkt.<br />
** sind derzeit noch nicht nicht overselled und haben ihren Krams scheinbar halbwegs sauber konfiguriert<br />
<br />
* [https://ipredator.se/ Ipredator] (Schweden, Niederlande, Deutschland)<br />
** (Glänzen nicht durch Kompetenz, da sie lange Zeit nur PPTP angeboten haben)<br />
** Mögen schnelle Reconnects nicht -> manchmal muss man OpenVPN ein paar Stunden deaktivieren, bevor es wieder funktioniert.<br />
** Möchten bald auch IPv6 anbieten.<br />
** Angeblich Reseller von relakks<br />
<br />
Ungetestet:<br />
* [https://www.anonine.com/en Anonine VPN] (Portlane)<br />
* [https://privacy.io/ privacy.io] (Portlane)<br />
* [http://prq.se/?p=tunnel&intl=1 prq.se] (Eigenes Netz, teuer)<br />
* [http://arethusa.su/vpn.html Arethusa VPN] (Loggen in Frankreich, andere Server angeblich nicht)<br />
<br />
Einige Freifunknetze mieten auch VMs in Osteuropa. Da die VMs noch nicht an ihre Grezen stößt könnte man diese auch mitnutzen. Ansprechpartner wäre s0ma.<br />
<br><br />
== Anbindung an andere Netze ==<br />
Es gibt drei relativ relevante Netzwerke bei denen es sich lohnt, das lokale Netz damit zu verbinden:<br />
<br />
* InterCity-VPN zwischen den meisten Freifunknetzen<br />
** BGP<br />
** kleine Übsicht der http://www.ddmesh.de/topology/ic-vpn-verbindungen.html<br />
** Mehr Infos http://wiki.freifunk.net/IC-VPN<br />
<br />
* DN42<br />
** BGP<br />
** Experimentelles Darknet zur Erprobung von Routing-Technologien und so weiter, wird privat betrieben. Viel interessantes Zeugs™<br />
** 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.<br />
<br />
* ChaosVPN<br />
** Tinc<br />
** Relativ großes „Darknet“ zwischen vielen Hackerspaces auf der ganzen Welt.<br />
<br><br />
== vServer-Anbieter die empfehlenswert sind ==<br />
* [https://www.de-punkt.de/vserver.html de-punkt] (Databurg, FFM)<br />
** Schneller Speicher, gut bezahlbar, KVM, nur Traffic-Flat™® das übliche.<br />
* [http://www.hetzner.de/hosting/produktmatrix_vserver/vserver-produktmatrix Hetzner] (Falkenstein)<br />
** Bezahlbar, 6.90€/TB Extratraffic, KVM<br />
** Achtung: Die Netzwerkarte der VM ist aus Kompatibilitätsgründen auf e1000 gesetzt. Diese "Netzwerkkarte" kommt nicht mit den vielen UDP-Paketen von fastd zurecht. Deshalb muss man vor Verwendung als Gateway die Netzwerkkarte auf "virtio" stellen.<br />
* [http://colorhost.de/server/vserver/ colorhost] (über 23media, Global Switch, FFM)<br />
* Untersagt Nutzung für Freifunk (http://colorhost.de/server/vserver/kvm/small/)<br />
** Achtung: Nur Xen oder Xen HVM funktionieren<br />
* [http://www.xirra.net/en/v-server/productmatrix/ xirra] (Core-Backbone, NBG)<br />
** KVM, TB-Traffic zu 5,95€. Langweilig und funktioniert. Pflegt bisher einen guten Kontakt zu Kunden.<br />
* [http://buyvm.net/ BuyVM]<br />
** 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.<br />
* [http://webhod.de webhod]<br />
** 9,99 € für die kleinste KVM im Monat[https://www.webhod.de/de/vserver/kvm.html]<br />
<br><br />
== Server-Anbieter die '''nicht''' empfehlenswert sind ==<br />
* [http://www.wrzhost.com/ WRZhost]<br />
** 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.<br />
<br />
* [https://www.netcup.de/ netcup]<br />
** V-Server laufen zwar grundsätzlich gut, allerdings halten sie sich nicht an ihre Versprechungen. Server wurde bereits mehrfach gedrosselt obwohl der Traffic weit unter den versprochenen 80 Mbit/s war (zwischen 30 und 40 Mbit/s). Die Drosselung tritt ohne Vorwarnung in Kraft und man kann seinen Server nicht mehr erreichen. Entdrosselung nur auf Nachfrage und dann auch nur mit einigem hin und her.<br />
<br><br />
= Grundinstallation des Servers =<br />
Vom ausgesuchten Hoster lassen wir uns eine aktuelle Linux-Distribution installieren oder ausliefern, wobei sich die Anleitung auf ein Debian 8 / Jessie bezieht.<br />
<br><br />
== Repositories und Update ==<br />
Als erstes werfen wir einen Blick in...<br />
<br />
<code><br />
vi /etc/apt/sources.list<br />
</code><br />
<br />
...und schauen, inwieweit auf die gleichen Software-Repositories verwiesen wird:<br />
<br />
<pre> <br />
deb http://security.debian.org/ jessie/updates main<br />
deb-src http://security.debian.org/ jessie/updates main<br />
<br />
deb http://ftp.de.debian.org/debian/ jessie main contrib non-free<br />
deb-src http://ftp.de.debian.org/debian/ jessie main contrib non-free<br />
<br />
deb http://ftp.de.debian.org/debian/ jessie-updates main<br />
deb-src http://ftp.de.debian.org/debian/ jessie-updates main<br />
<br />
</pre><br />
<br />
Danach bringen wir das System auf einen aktuellen Stand:<br />
<br />
<code><br />
apt-get update<br />
<br />
apt-get upgrade<br />
</code><br />
<br><br />
== Sicherheit ==<br />
Den SSH-Zugang besser schützen durch:<br />
* Änderung des Ports<br />
* login nur mit key<br />
* Siehe [http://www.thomas-krenn.com/de/wiki/Absicherung_eines_Debian_Servers hier] für genaue Anleitung: <br />
<br />
<code><br />
apt-get install fail2ban<br />
</code><br />
<br />
und [http://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban_absichern einrichten]<br />
<br />
So,nun sollte der Server ausreichend abgesichert sein.<br />
<br><br />
== B.A.T.M.A.N. adv 2013.4.0 Kernel-Modul ==<br />
Batman-Adv aus Jessie ist zu neu. Hier muss manuell das alte B.A.T.M.A.N. advanced 2013.4.0 gebaut werden.<br />
<br />
Hierfür benötigen wir minimal die Paketquellen build-essential, linux-headers-amd64 und git:<br />
<br />
<code><br />
apt-get install build-essential linux-headers-amd64 git gnupg-curl<br />
</code><br />
<br />
Die Softwarequellen müssen heruntergeladen...<br />
<code><br />
cd ~<br />
<br />
git clone https://github.com/freifunk-gluon/batman-adv-legacy<br />
<br />
cd batman-adv-legacy<br />
</code><br />
<br />
... und kompiliert und installiert werden:<br />
<br />
<code><br />
make<br />
<br />
make install<br />
</code><br />
<br />
Hinweis: Sollten noch Paketquellen fehlen, wird dies während des Kompilierens gemeldet. Die Software-Quellen müssen nachinstalliert werden und der letzte Kompilierungs- und Installationsschritt so lange wiederholt werden, bis die Software erfolgreich erstellt wurde.<br />
<br />
Nach erfolgreicher Erstellung kann das B.A.T.M.A.N Kernel Modul per modprobe händisch eingebunden werden:<br />
<br />
<code><br />
modprobe batman-adv<br />
</code><br />
<br />
Es sollte dann im Kernel-log ....<br />
<code><br />
dmesg | grep batman_adv<br />
</code><br />
<br />
... mit einem Eintrag gelistet werden:<br />
<pre><br />
batman_adv: B.A.T.M.A.N. advanced 2013.4.0-21-ga854277-dirty (compatibility version 14) loaded<br />
</pre><br />
<br />
Das Kernelmodul von B.A.T.M.A.N. kann dann bei jedem Neustart des Systems geladen werden, indem in die Datei /etc/modules:<br />
<br />
<code><br />
vi /etc/modules<br />
</code><br />
<br />
..der Eintrag "batman-adv" hinzugefügt wird:<br />
<br />
<pre><br />
batman-adv<br />
</pre><br />
<br><br />
== B.A.T.M.A.N adv 2013.4.0 batctl ==<br />
Gleiches gilt für batctl, ein Kommandozeilenprogramm zur B.A.T.M.A.N Konfiguration. Die alte Version 2013.4.0 muss selber gebaut werden, da die Debian 8 / Jessie Paketquellen zu neu sind.<br />
<br />
Herunterladen und Entpacken der Softwarequellen:<br />
<code><br />
cd ~<br />
<br />
wget http://downloads.open-mesh.org/batman/releases/batman-adv-2013.4.0/batctl-2013.4.0.tar.gz<br />
<br />
tar xzf batctl-2013.4.0.tar.gz<br />
<br />
cd batctl-2013.4.0<br />
</code><br />
<br />
Kompilieren und Installieren:<br />
<br />
<code><br />
make<br />
<br />
make install<br />
</code><br />
<br />
Hinweis: Auch hier müssen ggf. fehlende Quellen händisch nachinstalliert und das Kompilieren und Installieren bis zum Erfolg wiederholt werden.<br />
<br><br />
== FastD ==<br />
Die Verbindung zwischen Gateway und Router wird über einen fastd-Tunnel realisiert.<br />
<br />
Hierfür müssen wir ein neues Repository in der Datei /etc/apt/sources.list deklarieren:<br />
<br />
<code><br />
vi /etc/apt/sources.list.d/universe-factory.list<br />
</code><br />
<br />
Dort fügen wir folgendes Repository an:<br />
<br />
<pre><br />
deb http://repo.universe-factory.net/debian/ sid main<br />
deb-src http://repo.universe-factory.net/debian/ sid main<br />
</pre><br />
<br />
Danach die PGP Schlüssel holen:<br />
<code><br />
gpg --keyserver hkps://hkpspool.sks-keyservers.net --recv-key 16EF3F64CB201D9C<br />
<br />
gpg -a --export 16EF3F64CB201D9C | apt-key add -<br />
</code><br />
<br />
Datenbankupdate der Paketverwaltung:<br />
<code><br />
apt-get update<br />
</code><br />
<br />
Installation von fastd: <br />
<code><br />
apt-get install fastd <br />
</code><br />
<br><br />
== OpenVPN ==<br />
OpenVPN (falls benötigt) installieren wir mit:<br />
<code><br />
apt-get install openvpn<br />
</code><br />
<br><br />
== DHCP ==<br />
Den DHCP Server installieren wir mit:<br />
<code><br />
apt-get install isc-dhcp-server <br />
</code><br />
<br><br />
== Bind9 ==<br />
Als DNS Server nehmen wir hier den de-facto-Standard bind:<br />
<code><br />
apt-get install bind9 <br />
</code><br />
<br><br />
== OLSR ==<br />
Als Routing-Protokoll, um die einzelnen Hoods später zu einem Freifunk-Franken weit kommunizierenden Netz zu verbinden, wird OLSR installiert:<br />
<br />
<code><br />
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd_0.6.8.1-1_amd64.deb<br />
<br />
dpkg -i olsrd_0.6.8.1-1_amd64.deb<br />
<br />
wget http://ftp.freifunk-franken.de/firmware/olsrd/jessie/olsrd-plugins_0.6.8.1-1_amd64.deb<br />
<br />
dpkg -i olsrd-plugins_0.6.8.1-1_amd64.deb<br />
<br />
</code><br />
<br><br />
= Konfigurieren des Freifunk-Gateways =<br />
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 />
<br><br />
== IPv4 des Gateways, IP-Bereich der Hood und DHCP Range des Gateway==<br />
Für das Gateway suchen wir uns unter [[Portal:Netz]] eine IPv4 Adresse aus dem statischen Range der Hood aus. Für Fürth läuft der Bereich für die statischen Adressen z.B. von 10.50.32.1 - 10.50.32.255. Hiervon suchen wir uns eine '''freie''' Adresse aus, und reservieren diese, indem wir sie weiter unten in die Tabelle der statischen IPs eintragen.<br />
<br />
Die Fürther Hood hat den IP-Bereich 10.50.32.0-10.50.32.255. Als Netzwerk wird dieser Bereich mit 10.50.32.0/21 deklariert, d.h. die ersten 21 Bit der IP identifizieren das Netzwerk "Fürther Hood" und die restlichen 11 Bit stehen zur IP Vergabe zur Verfügung, wobei Anfang (10.50.32.0) und Ende des Bereiches (10.50.39.255) reserviert sind und nicht, weder statisch noch dynamisch durch DHCP, belegt werden dürfen. Eine alternative Schreibweise zu 10.50.32.0/21 ist das Double "Network 10.50.32.0" und "Netmask 255.255.248.0". Ein entsprechender IP-Rechner zur analogen Anwendung in anderen Hoods findet sich z.B. [http://www.heise.de/netze/tools/netzwerkrechner/ hier].<br />
<br />
Ebenso sollte man einen DHCP-Bereich innerhalb des IP-Bereichs der jeweiligen Hood, die der GW bedienen soll, reservieren (d.h. in die oberer Tabelle unter [[Portal:Netz]] eintragen). Jeder DHCP-Server vergibt dynamisch IPv4 Adressen an Clients aus einem vorher definierten Adressbereich. Dieser Adressbereich sollte sich:<br />
* innerhalb des IP-Range der Hood bewegen<br />
* sich nicht mit dem Adressbereich überschneiden, den andere DHCP Server in der Hood verwalten<br />
* sich nicht mit dem Bereich der statischen Adressen der Hood überschneiden<br />
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. Vom gesamten IP-Bereich der Fürther Hood vergibt z.B. das Gateway fff-nue1 die Teilmenge 10.50.35.0 - 10.50.36.255 an Clients und teilt ihnen auf dem Weg auch gleich mit, wie sie Domain-Namen in IPs auflösen und auf welchem Weg sie ins Internet oder in andere Hoods kommen.<br />
<br><br />
== Routing Tabelle für Freifunk ==<br />
Fürs Routing im Freifunk Franken Netz wird eine eigene Routing Tabelle namens "fff" deklariert.<br />
<br />
Dies geschieht indem man in der Datei /etc/iproute2/rt_tables ...<br />
<code><br />
vi /etc/iproute2/rt_tables<br />
</code><br />
<br />
... folgendes am Ende einfügt:<br />
<br />
<pre><br />
10 fff<br />
</pre><br />
<br />
Unsere Freifunk Routing Tabelle lässt sich später durch<br />
<code><br />
ip route show table fff<br />
</code><br />
anzeigen, sobald wir die Tabelle mit Einträgen füllen.<br />
<br><br />
== B.A.T.M.A.N Netzwerk-Interface, fff Routingregeln und -tabelle ==<br />
'''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.<br />
<br />
In der Datei /etc/network/interfaces ...<br />
<br />
<code><br />
vi /etc/network/interfaces<br />
</code><br />
<br />
fügen wir zunächst folgenden Textblock des Gateways "klee" aus der Fürther Hood an:<br />
<br />
<pre><br />
.<br />
.<br />
.<br />
# device: bat0<br />
iface bat0 inet manual<br />
post-up ifconfig $IFACE up<br />
##Einschalten post-up:<br />
# IP des Gateways am B.A.T.M.A.N interface:<br />
post-up ip addr add 10.50.32.5/21 dev $IFACE<br />
# Regeln, wann die fff Routing-Tabelle benutzt werden soll: <br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.0.0.0/8 table fff <br />
post-up ip rule add to 10.0.0.0/8 table fff<br />
# Route in die Fuerther Hood: <br />
post-up ip route add 10.50.32.0/21 dev $IFACE table fff<br />
# Start des DHCP Servers:<br />
post-up invoke-rc.d isc-dhcp-server restart<br />
<br />
##Ausschalten post-down:<br />
# Loeschen von oben definieren Routen, Regeln und Interface: <br />
post-down ip route del 10.50.32.0/21 dev $IFACE table fff<br />
post-down ip rule del from 10.0.0.0/8 table fff<br />
post-down ip rule del to 10.0.0.0/8 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ifconfig $IFACE down<br />
<br />
# VPN Verbindung in die Fuerther Hood<br />
iface ffffuerthVPN inet manual<br />
post-up batctl -m bat0 if add $IFACE<br />
post-up ifconfig $IFACE up<br />
post-up ifup bat0<br />
post-down ifdown bat0<br />
post-down ifconfig $IFACE down<br />
</pre><br />
<br />
In diesem Beispiel sind:<br />
* IP des Gateway/Netzmaske der Fürther Hood: 10.50.32.5/21<br />
* IP des Netzwerks Fürther Hood / Netzmaske der Fürther Hood: 10.50.32.0/21.<br />
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.<br />
<br />
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.).<br />
<br />
Die Regeln definieren, das Traffic der<br />
* aus dem Netzwerk 10.0.0.0/8 kommt<br />
* das Netzwerk 10.0.0.0/8 zum Ziel hat<br />
* oder über die B.A.T.M.A.N Schnittstelle übermittelt wird<br />
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.<br />
<br />
Im post-down Abschnitt werden die vorher definierten Regeln, Interfaces und Routen wieder gelöscht.<br />
<br />
Der untere Abschnitt definiert einen VPN Tunnel in die Fürther Hood. Der Name des Interfaces im Beispiel (ffffuerthVPN) kann individuell neu vergeben werden.<br />
<br><br />
== FastD Start- und Verwaltungsscript ==<br />
Für die Konfiguration von fastd importieren wir eine Datei in ''/etc/fastd'' mit dem Befehl:<br />
<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/fff_beispiel_fastd.sh -P /etc/fastd/<br />
</code><br />
<br />
Alternativ kann das Skript aus einer leeren Datei erstellt werden:<br />
<code><br />
touch /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
danach öffnen wir diese:<br />
<br />
<code><br />
vi /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
und editieren das Skript oder fügen ein Neues ein:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
SERVERNAME="beispiel"<br />
<br />
hood="hoodeintragen"<br />
project="fff"<br />
port=10004<br />
<br />
SERVERNAME="$SERVERNAME.$hood"<br />
<br />
hostname=$SERVERNAME<br />
<br />
if [ ! -d /etc/fastd ]<br />
then<br />
mkdir /etc/fastd<br />
fi<br />
<br />
if [ ! -d /etc/fastd/$project.$hood ]<br />
then<br />
mkdir /etc/fastd/$project.$hood<br />
mkdir /etc/fastd/$project.$hood/peers<br />
<br />
#fastd config<br />
(<br />
echo "# Log warnings and errors to stderr"<br />
echo "log level error;"<br />
echo "# Log everything to a log file"<br />
echo "log to syslog as \"${project}${hood}\" level info;"<br />
echo "# Set the interface name"<br />
echo "interface \"${project}${hood}VPN\";"<br />
echo "# Support xsalsa20 and aes128 encryption methods, prefer xsalsa20"<br />
echo "#method \"xsalsa20-poly1305\";"<br />
echo "#method \"aes128-gcm\";"<br />
echo "method \"null\";"<br />
echo "# Bind to a fixed port, IPv4 only"<br />
echo "bind any:${port};"<br />
echo "# Secret key generated by \"fastd --generate-key\""<br />
echo "secret \"$(fastd --generate-key | grep -i Secret | awk '{print $2}')\";" <br />
echo "# Set the interface MTU for TAP mode with xsalsa20/aes128 over IPv4 with a base MTU of 1492 (PPPoE)" <br />
echo "# (see MTU selection documentation)" <br />
echo "mtu 1426;" <br />
echo "on up \"/etc/fastd/${project}.${hood}/up.sh\";" <br />
echo "on post-down \"/etc/fastd/${project}.${hood}/down.sh\";" <br />
echo "# Include peers from the directory 'peers'" <br />
echo "include peers from \"/etc/fastd/${project}.${hood}/peers\";" <br />
echo "secure handshakes no;"<br />
) >> "/etc/fastd/$project.$hood/$project.$hood.conf"<br />
<br />
#fastd-up<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifdown \$INTERFACE"<br />
) >> /etc/fastd/$project.$hood/down.sh<br />
<br />
chmod +x /etc/fastd/$project.$hood/down.sh<br />
<br />
(<br />
echo "#!/bin/sh"<br />
echo "/sbin/ifup \$INTERFACE" >> /etc/fastd/$project.$hood/up.sh<br />
) >> /etc/fastd/$project.$hood/up.sh<br />
chmod +x /etc/fastd/$project.$hood/up.sh<br />
fi<br />
<br />
pubkey=$(fastd -c /etc/fastd/$project.$hood/$project.$hood.conf --show-key --machine-readable)<br />
port=$(grep ^bind /etc/fastd/$project.$hood/$project.$hood.conf | cut -d: -f2 | cut -d\; -f1)<br />
<br />
# fire up<br />
if [ "$(/sbin/ifconfig -a | grep -i ethernet | grep ${project}${hood}VPN)" = "" ]<br />
then<br />
/bin/rm /var/run/fastd.$project.$hood.pid<br />
fastd -c /etc/fastd/$project.$hood/$project.$hood.conf -d --pid-file /var/run/fastd.$project.$hood.pid<br />
fi<br />
<br />
# register<br />
wget -T15 -q "http://keyserver.freifunk-franken.de/${project}/?name=$hostname&port=$port&key=$pubkey" -O /tmp/fastd_${project}.${hood}_output <br />
if [ "$?" != "0" ]<br />
then<br />
echo "Update failed"<br />
echo "Exiting, no clean up, no refresh"<br />
exit<br />
fi<br />
<br />
touch /tmp/fastd_${project}.${hood}_starting<br />
<br />
filenames=$(cat /tmp/fastd_${project}.${hood}_output| grep ^#### | sed -e 's/^####//' | sed -e 's/.conf//g')<br />
for file in $filenames<br />
do<br />
grep -A100 ^####$file.conf$ /tmp/fastd_${project}.${hood}_output | grep -v ^####$file.conf$ | grep -m1 ^### -B100 | grep -v ^### | sed 's/ float;/;/g' > "/etc/fastd/$project.$hood/peers/$file"<br />
echo 'float yes;' >> "/etc/fastd/$project.$hood/peers/$file"<br />
done<br />
<br />
#find old peers<br />
OLD=$(find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print)<br />
<br />
if [ -n "${OLD}" ] ; then<br />
echo "Lösche alte:"<br />
echo $OLD<br />
<br />
find /etc/fastd/$project.$hood/peers/ -exec test -f '{}' -a /tmp/fastd_${project}.${hood}_starting -nt '{}' \; -print | xargs /bin/rm /tmp/fastd_${project}.${hood}_starting<br />
fi<br />
<br />
#reload<br />
kill -HUP "$(cat /var/run/fastd.$project.$hood.pid)"<br />
<br />
exit 0<br />
</pre><br />
<br />
Zum Schluss geben wir noch ein<br />
<br />
<code><br />
chmod +x /etc/fastd/fff_beispiel_fastd.sh<br />
</code><br />
<br />
ein, um das Skript ausführbar zu machen.<br />
<br />
Das Skript konfiguriert fastd, indem es<br />
* einen Schlüssel generiert, sollte keiner existieren<br />
* diesen Schlüssel mit dem Keyserver austauscht<br />
* die fastd Konfigurationsdatei anlegt<br />
* den fastd Dämonen startet<br />
<br />
Lediglich der Servername und die Hood müssen oben im Skript händisch angepasst werden. Der Dateiname des Skripts kann individuell angepasst werden.<br />
<br />
Nachdem das Script ausgeführt wurde, sollte man überprüfen ob das Interface in der Konfigurationsdatei unter /etc/fastd/fff.<Hoodname>/fff.<Hoodname>.conf das gleiche ist wie vorher in /etc/network/interfaces festgelegt. Wenn der Name nicht identisch ist (Groß-/Kleinschreibung), werden die Interfaces nicht starten.<br />
<br />
Hinweis: Das Gateway wird standardmässig in die Default-Hood eingebunden. Es wird hier lediglich ein Name für die Konfigurationsdatei und der Gateway Name definiert. Die Zuordnung des Gateways zu der Hood erfolgt später über den KeyXchange (siehe unten).<br />
<br><br />
== IP-Forwarding ==<br />
Um Anfragen, die das Gateway erreichen, weiterzuleiten, muss IP-Forwarding aktiviert werden. <br />
<br />
Manuell geht dies über:<br />
<code><br />
echo "1" > /proc/sys/net/ipv4/ip_forward<br />
<br />
echo "1" > /proc/sys/net/ipv6/conf/default/forwarding<br />
<br />
echo "1" > /proc/sys/net/ipv6/conf/all/forwarding<br />
</code><br />
<br />
Dauerhaft lässt sich IP-Forwarding in /etc/sysctl.conf aktivieren:<br />
<code><br />
vi /etc/sysctl.conf<br />
</code><br />
<br />
.. um dort die Abschnitte einzukommentieren, die das Forwarding steuern:<br />
<pre><br />
.<br />
.<br />
.<br />
# Uncomment the next line to enable packet forwarding for IPv4<br />
net.ipv4.ip_forward=1<br />
<br />
# Uncomment the next line to enable packet forwarding for IPv6<br />
# Enabling this option disables Stateless Address Autoconfiguration<br />
# based on Router Advertisements for this host<br />
net.ipv6.conf.all.forwarding=1<br />
.<br />
.<br />
.<br />
</pre><br />
<br><br />
== Testen von B.A.T.M.A.N, fastd und Autostart ==<br />
Hierfür booten wir das Gateway am besten erst mal neu:<br />
<code><br />
reboot & exit<br />
</code><br />
<br />
und starten das fast.d Startskript manuell: <br />
<code><br />
/etc/fastd/fff_beispiel_fastd.sh &<br />
</code><br />
<br />
Beim Erststart werden Schlüsselpaare generiert und ausgetauscht, es kann also etwas dauern.<br />
<br />
Danach sollte der Aufruf von...<br />
<code><br />
pgrep fastd<br />
</code><br />
... mit der Prozess-ID beantwortet werden: Fastd läuft in dem Fall.<br />
<br />
<br />
Ein Aufruf von ifconfig:<br />
<code><br />
ifconfig<br />
</code><br />
<br />
sollte die neu erstellten Interfaces bat0 und ffffuerthVPN zurückliefern.<br />
Exemplarisch und als Auszug:<br />
<pre><br />
bat0 Link encap:Ethernet HWaddr ea:95:50:07:f7:27 <br />
inet addr:10.50.32.5 Bcast:0.0.0.0 Mask:255.255.248.0<br />
inet6 addr: fe80::e895:50ff:fe07:f727/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:1089992 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:849698 errors:0 dropped:1728 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0 <br />
RX bytes:141311612 (134.7 MiB) TX bytes:1052934594 (1004.1 MiB)<br />
<br />
.<br />
.<br />
.<br />
ffffuerthVPN Link encap:Ethernet HWaddr e6:3b:f3:b7:fc:db <br />
inet6 addr: fe80::e43b:f3ff:feb7:fcdb/64 Scope:Link<br />
UP BROADCAST RUNNING MULTICAST MTU:1426 Metric:1<br />
RX packets:32389694 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:2699525 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:500 <br />
RX bytes:4193328694 (3.9 GiB) TX bytes:1384843740 (1.2 GiB)<br />
.<br />
.<br />
.<br />
</pre><br />
Aus dem ifconfig Auszug für bat0 sollte die eingerichtete IP des Gateways und die Netzmaske hervorgehen.<br />
<br />
<br />
Die Abfrage der IP-Regeln:<br />
<code><br />
ip rule<br />
</code><br />
<br />
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):<br />
<pre><br />
32757: from all to 10.0.0.0/8 lookup fff <br />
32758: from 10.0.0.0/8 lookup fff <br />
32759: from all iif bat0 lookup fff <br />
</pre><br />
<br />
Eine Abfrage der fff-Routing Tabelle<br />
<code><br />
ip route show table fff <br />
</code><br />
<br />
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:<br />
<pre><br />
10.50.32.0/21 dev bat0 scope link<br />
</pre><br />
<br />
Ein Aufruf von "batctl o"<br />
<code><br />
batctl o <br />
</code><br />
<br />
ergibt eine Liste der MAC-Adressen von unseren nächsten Nachbarn. Exemplarisch und als Auszug:<br />
<pre><br />
[B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: ffffuerthVPN/e6:3b:f3:b7:fc:db (bat0)]<br />
Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ...<br />
96:43:c4:2e:73:68 0.004s (255) 96:43:c4:2e:73:68 [ffffuerthVPN]: 96:43:c4:2e:73:68 (255)<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
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:<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
Hier spendieren wir einen Eintrag, der fastd mit 10 Sekunden Verzögerung bei jedem Systemstart mitstartet:<br />
<pre><br />
# launch fastd with 10 seconds delay<br />
(sleep 10; sh /etc/fastd/fff_beispiel_fastd.sh) &<br />
</pre><br />
<br />
'''Zusätzlich''' muss ein Cronjob angelegt werden, der das Skript z.B. alle 10 Minuten ausführt:<br />
<code><br />
crontab -e<br />
</code><br />
<br />
Nun folgendes eingeben:<br />
<pre><br />
*/10 * * * * sh /etc/fastd/fff_beispiel_fastd.sh<br />
</pre><br />
<br />
und<br />
<br />
<code><br />
/etc/init.d/cron restart<br />
</code><br />
<br><br />
== OpenVPN-Tunnel einrichten ==<br />
Die Einrichtung eines OpenVPN Tunnels kann von Anbieter zu Anbieter variieren. <br />
Im Laufe der Zeit sollte die Dokumentation so um funktionierende Konfigurationen verschiedener Anbieter erweitert werden.<br />
<br><br />
=== Mullvad ===<br />
Mullvad liefert in der Datei mullvadconfig.zip, die notwendigen Schlüssel (ca.crt, mullvad.crt, mullvad.key) als auch eine Konfigurationsdatei (mullvad_linux.conf) mit, die später angepasst werden muss.<br />
<br />
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:<br />
<br />
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.<br />
<br />
Als unverbindliche Richtschnur für Linux:<br />
<code><br />
scp mullvadconfig.zip root@<ipv4 des Gateways>:/root<br />
</code><br />
<br />
Danach loggen wir uns auf dem Gateway ein und entpacken die Datei (nicht vergessen unzip zu installieren):<br />
<code><br />
ssh root@<ipv4 des Gateways><br />
<br />
unzip mullvadconfig.zip<br />
<br />
cd <Kundennummernverzeichnis><br />
<br />
cp * /etc/openvpn<br />
</code><br />
<br />
''/etc/openvpn/'' sollte mit dem Inhalt des entpackten mullvadconfig.zip Archivs dann so aussehen:<br />
<pre><br />
ca.crt crl.pem mullvad.crt mullvad.key mullvad_linux.conf mullvad-up mullvad_windows.conf.ovpn <br />
</pre><br />
<br />
'''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.<br />
<br />
Wir legen ein benutzerspezifisches start-up Script namens mullvad-up an:<br />
<code><br />
vi /etc/openvpn/mullvad-up<br />
</code><br />
<br />
und füllen sie mit folgendem Inhalt:<br />
<pre><br />
#!/bin/bash<br />
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE<br />
</pre><br />
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.<br />
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.<br />
<br />
Das Skript mullvad-up muss ferner ausführbar sein:<br />
<code><br />
chmod +x /etc/openvpn/mullvad-up<br />
</code><br />
<br />
Dieses spezifische Routing muss zwingend in mullvad_linux.conf eingepflegt werden:<br />
<code><br />
vi /etc/openvpn/mullvad_linux.conf<br />
</code><br />
<br />
und hier die Konfiguration entsprechend geändert werden:<br />
<pre><br />
.<br />
.<br />
.<br />
# Allow calling of built-in executables and user-defined scripts.<br />
script-security 2<br />
<br />
# Parses DHCP options from openvpn to update resolv.conf<br />
#up /etc/openvpn/update-resolv-conf<br />
#down /etc/openvpn/update-resolv-conf<br />
<br />
# Enable Freifunk specific Routing<br />
route-noexec<br />
route-delay 3<br />
route-up /etc/openvpn/mullvad-up<br />
.<br />
.<br />
.<br />
</pre><br />
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.<br />
<br />
Wer möchte, kann in mullvad_linux.conf auch Länder definieren, über die der VPN Traffic laufen soll (Ein- /Auskommentieren).<br />
<br />
Der openvpn Tunnel kann nun testweise gestartet werden:<br />
<code><br />
cd /etc/openvpn<br />
<br />
/usr/sbin/openvpn mullvad_linux.conf &<br />
</code><br />
<br />
und sollte exemplarisch und im Auszug folgendes zurück liefern:<br />
<pre><br />
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<br />
Sun Sep 6 12:45:20 2015 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08<br />
Sun Sep 6 12:45:20 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts<br />
.<br />
.<br />
.<br />
Sun Sep 6 12:45:23 2015 /sbin/ip link set dev tun0 up mtu 1500<br />
Sun Sep 6 12:45:23 2015 /sbin/ip addr add dev tun0 10.114.0.45/16 broadcast 10.114.255.255<br />
Sun Sep 6 12:45:23 2015 /sbin/ip -6 addr add fdef:e287:a479:72::102b/112 dev tun0<br />
Sun Sep 6 12:45:23 2015 /etc/openvpn/mullvad-up tun0 1500 1558 10.114.0.45 255.255.0.0 init<br />
Sun Sep 6 12:45:23 2015 Initialization Sequence Completed<br />
</pre><br />
Wichtig ist hierbei, dass in der vorletztes Zeile unser Freifunk-spezifisches Routing durchgeführt wird.<br />
<br />
Das VPN-Gateway sollte nun als Default Route in der fff-Routingtabelle auftauchen:<br />
<code><br />
ip route show table fff | grep default<br />
</code><br />
<br />
Exemplarisch wäre eine Ausgabe für das Tunnel-Device tun0 und dem VPN-Gateway 10.114.0.1:<br />
<pre><br />
default via 10.114.0.1 dev tun0<br />
</pre><br />
<br />
Auch ein ifconfig Eintrag für das Tunnel Device...<br />
<code><br />
ifconfig<br />
</code><br />
<br />
...sollte jetzt existieren (Exemplarisch und im Auszug):<br />
<pre><br />
.<br />
.<br />
.<br />
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 <br />
inet addr:10.114.0.76 P-t-P:10.114.0.76 Mask:255.255.0.0<br />
inet6 addr: fdad:bdef:735d:72::104a/112 Scope:Global<br />
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1<br />
RX packets:1012476 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:640206 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:100 <br />
RX bytes:1250196616 (1.1 GiB) TX bytes:84979294 (81.0 MiB)<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
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:<br />
<code><br />
vi /etc/rc.local <br />
</code><br />
<br />
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:<br />
<pre><br />
# launch vpn with 5 seconds delay<br />
(sleep 5; /usr/sbin/openvpn /etc/openvpn/mullvad_linux.conf >> /var/log/mullvad_vpn.log &) &<br />
</pre><br />
<br><br />
<br />
=== NordVPN ===<br />
NordVPN liefert die Datei config.zip mit, die für jeden verwendbaren VPN-Server eine seperate Konfigurationsdatei enthält.<br />
<br />
'''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.<br />
<br />
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.<br />
<br />
Als unverbindliche Richtschnur für Linux:<br />
<code><br />
scp config.zip root@<ipv4 des Gateways>:/root<br />
</code><br />
<br />
Und entpacken diese auf dem Gateway:<br />
<code><br />
cd ~<br />
<br />
mkdir nordvpn-configs<br />
<br />
mv config.zip nordvpn-configs<br />
<br />
cd nordvpn-configs<br />
<br />
unzip config.zip<br />
</code><br />
<br />
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.<br />
<br />
Im Beispiel nehmen wir se1.nordvpn.com.udp1194.ovpn und passen Sie zunächst Freifunk-spezifisch an (siehe Aussperr-Hinweis oben):<br />
<br />
<code><br />
vi se1.nordvpn.com.udp1194.ovpn<br />
</code><br />
<br />
Ä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:<br />
<pre><br />
.<br />
.<br />
.<br />
# Provide Username and Password<br />
auth-user-pass /etc/openvpn/nordvpn-pw<br />
.<br />
.<br />
.<br />
# Allow calling of built-in executables and user-defined scripts.<br />
script-security 2<br />
<br />
# Enable Freifunk specific Routing<br />
route-noexec<br />
route-delay 3<br />
route-up /etc/openvpn/nordvpn-up<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
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:<br />
<code><br />
cp se1.nordvpn.com.udp1194.ovpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf<br />
</code><br />
<br />
Hier legen wir noch unser Freifunk Startskript und unsere Password Datei an und machen das Skript ausführbar:<br />
<code><br />
touch /etc/openvpn/nordvpn-up<br />
<br />
touch /etc/openvpn/nordvpn-pw<br />
<br />
chmod +x /etc/openvpn/nordvpn-up<br />
</code><br />
<br />
Man öffnet nordvpn-up...<br />
<code><br />
vi /etc/openvpn/nordvpn-up<br />
</code><br />
<br />
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):<br />
<pre><br />
#!/bin/bash<br />
logger -t OPENVPN VPN Gateway: /sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
/sbin/ip route add default via ${route_vpn_gateway} dev ${dev} table fff<br />
iptables -t nat -A POSTROUTING -o ${dev} -j MASQUERADE<br />
</pre><br />
<br />
Nun öffnet man nordvpn-pw:<br />
<code><br />
vi /etc/openvpn/nordvpn-pw<br />
</code><br />
<br />
Und legt in der ersten Zeile der Datei seinen NordVPN Usernamen und in der zweiten Zeile sein NordVPN Passwort ab:<br />
<pre><br />
(Username bei NordVPN)<br />
(Password bei NordVPN)<br />
</pre><br />
<br />
Der Tunnel kann nun testweise gestartet werden (hier im Beispiel mit der Konfigurationsdatei se1.nordvpn.com.udp1194.ovpn)<br />
<code><br />
openvpn /etc/openvpn/se1.nordvpn.com.udp1194.ovpn.conf &<br />
</code><br />
<br />
Und sollte aufgebaut werden:<br />
<pre><br />
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<br />
.<br />
.<br />
.<br />
Sun Sep 27 09:07:15 2015 /sbin/ip link set dev tun0 up mtu 1500<br />
Sun Sep 27 09:07:15 2015 /sbin/ip addr add dev tun0 local 10.8.8.226 peer 10.8.8.225<br />
Sun Sep 27 09:07:18 2015 Initialization Sequence Completed<br />
</pre><br />
<br />
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:<br />
<code><br />
vi /etc/rc.local <br />
</code><br />
<br />
und dort z.B. ein zeitverzögertes Starten nach 5 Sekunden vereinbaren:<br />
<pre><br />
# launch vpn with 5 seconds delay<br />
(sleep 5; cd /etc/openvpn ; /usr/sbin/openvpn se1.nordvpn.com.udp1194.ovpn.conf >> /var/log/nordvpn.log &) &<br />
</pre><br />
Die Beispiel-Konfigurationsdatei (se1.nordvpn.com.udp1194.ovpn.conf) muss entsprechend angepasst werden.<br />
<br><br />
== DNS Server ==<br />
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.<br />
<br />
----<br />
<br />
'''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.'''<br />
<br />
----<br />
<br />
Hierfür editieren wir die Datei named.conf.options...<br />
<code><br />
vi /etc/bind/named.conf.options<br />
</code><br />
<br />
...und tragen die DNS Server, die wir anfragen wollen, wenn wir die Information nicht selber haben, als forwarders ein:<br />
<pre><br />
.<br />
.<br />
.<br />
forwarders {<br />
10.50.32.1;<br />
10.50.32.2;<br />
8.8.8.8;<br />
};<br />
allow-query { <br />
127.0.0.1/8; <br />
10.0.0.0/8; <br />
};<br />
.<br />
.<br />
. <br />
</pre><br />
In diesem Fall werden die Freifunk Gateways ro1 (10.50.32.1) und fff-nue1 (10.50.32.2) der Fürther Hood als auch Google DNS (8.8.8.8) als Forwarders definiert. Für andere Hoods muss die lokale Adresse der Freifunk DNS Server unter [[Portal:Netz]] ermittelt werden (z.B. 10.50.48.1 für ro1 in der Ansbacher Hood).<br />
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".<br />
<br />
Neustart des DNS-Servers mit der neuen Konfiguration:<br />
<code><br />
/etc/init.d/bind9 restart<br />
</code><br />
<br />
Testen können wir, indem wir vom DNS Server des Gateways (localhost/127.0.0.1) eine DNS-Auflösung abfragen. <br />
<br />
Ein DNS Resolve für freifunk-franken.de ...<br />
<code><br />
dig @127.0.0.1 freifunk-franken.de<br />
</code><br />
<br />
...sollte von uns selber (Server localhost; 127.0.0.1) beantwortet werden:<br />
<pre><br />
;; global options: +cmd<br />
<br />
;; Got answer:<br />
<br />
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5819<br />
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1 <br />
;; OPT PSEUDOSECTION:<br />
; EDNS: version: 0, flags:; udp: 4096<br />
<br />
;; QUESTION SECTION:<br />
;freifunk-franken.de. IN A<br />
;; ANSWER SECTION:<br />
freifunk-franken.de. 3599 IN A 31.172.113.113 <br />
.<br />
. <br />
.<br />
;; Query time: 117 msec<br />
;; SERVER: 127.0.0.1#53(127.0.0.1)<br />
;; WHEN: Tue Sep 08 14:16:32 EEST 2015<br />
;; MSG SIZE rcvd: 275<br />
</pre><br />
<br><br />
<br />
== B.A.T.M.A.N Gateway Selection ==<br />
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.<br />
<br />
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:<br />
* Bandbreite der Netzanbindung (z.B. 100 Mbit/sec, gesplittet in 50 Mbit/sec up/down)<br />
* 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)<br />
* Erfahrungswerten / eigenes Ermessen<br />
* Bandbreite, bei dem der Gateway Prozessor ausgelastet ist<br />
<br />
Eventuell muss zuerst bc nachinstalliert werden, falls nicht vorhanden:<br />
<code><br />
apt-get install bc<br />
</code><br />
<br />
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.<br />
<br />
Importieren des Skripts aus einer Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/dyn_announce_gw_bw.sh -P /usr/local/bin/<br />
</code><br />
<br />
Alternativ kann das Skript auch als leere Datei erstellt werden:<br />
<code><br />
touch /usr/local/bin/dyn_announce_gw_bw.sh<br />
</code><br />
<br />
Wir machen das Skript ausführbar und öffnen die Datei:<br />
<code><br />
chmod +x /usr/local/bin/dyn_announce_gw_bw.sh<br />
<br />
vi /usr/local/bin/dyn_announce_gw_bw.sh<br />
</code><br />
<br />
Und Füllen dieses mit Inhalt oder editieren den importierten Inhalt:<br />
<pre><br />
#!/bin/bash<br />
<br />
<br />
if [ -z "$1" ]; then<br />
echo<br />
echo "usage: $0 <network-interface> <update_interval [sec]> <total BW up [Mbit/sec]> <total BW down [Mbit/sec]>"<br />
echo<br />
echo "e.g. $0 eth0 60 10 10"<br />
echo<br />
exit<br />
fi<br />
<br />
while true<br />
do<br />
# Bandwidth currently used (time averaged)<br />
R1=$(cat "/sys/class/net/$1/statistics/rx_bytes")<br />
T1=$(cat "/sys/class/net/$1/statistics/tx_bytes")<br />
sleep "$2"<br />
R2=$(cat "/sys/class/net/$1/statistics/rx_bytes")<br />
T2=$(cat "/sys/class/net/$1/statistics/tx_bytes")<br />
TkbitPS=$(echo "scale=0; ($T2 - $T1) / 1024 * 8 / $2" | bc -l)<br />
RkbitPS=$(echo "scale=0; ($R2 - $R1) / 1024 * 8 / $2" | bc -l)<br />
# echo "BW used -- up $1: $TkbitPS kBit/s; down $1: $RkbitPS kBit/s"<br />
<br />
# Remaining bandwidth available; cut-off negative values<br />
Tavail_kbitPS=$(echo "scale=0; if (($3 * 1024 - $TkbitPS) >0) ($3 * 1024 - $TkbitPS) else 0" | bc -l)<br />
Ravail_kbitPS=$(echo "scale=0; if (($4 * 1024 - $RkbitPS) >0) ($4 * 1024 - $RkbitPS) else 0" | bc -l)<br />
# echo "BW available -- up $1: $Tavail_kbitPS kBit/s; down $1: $Ravail_kbitPS kBit/s"<br />
<br />
# Pass calculated figures to B.A.T.M.A.N Gateway Selection<br />
for bat in /sys/class/net/bat*; do<br />
iface=${bat##*/}<br />
batctl -m $iface gw_mode server "${Ravail_kbitPS}kbit/${Tavail_kbitPS}kbit" <br />
done<br />
<br />
done<br />
</pre><br />
<br />
Das Skript übernimmt als Parameter:<br />
* Netzwerkinterface, das es zu überwachen gilt (i.d.R. eth0)<br />
* 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)<br />
* Upload Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)<br />
* Download Kapazität in Mbit/sec (insgesamt zur Verfügung stehend s.o.)<br />
<br />
Ein Aufruf für eth0 als Interface, ein Update alle 120 Sekunden, 12 Mbit/sec maximaler Upload und 10 Mbit/sec maximaler Download wäre z.B.:<br />
<code><br />
/usr/local/bin/dyn_announce_gw_bw.sh eth0 120 12 10<br />
</code><br />
<br />
Um die Gateway Selection beim Systemsstart zu aktivieren, können wir das Skript z.B. in rc.local aufrufen:<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
um dort, leicht zeitverzögert, o.a. Befehl einzupflegen, wobei die Parametrisierung noch Gateway-spezifisch angepasst werden muss:<br />
<pre><br />
.<br />
.<br />
.<br />
#enable batman GW selection with 15 seconds delay<br />
(sleep 15; /usr/local/bin/dyn_announce_gw_bw.sh eth0 120 12 10) &<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
ACHTUNG! Bei mehreren bat Interfaces (weil man in mehreren Hoods Gateway ist) muss diese Einstellung für jedes Gateway gesetzt werden, hier muss das Script unbedingt überarbeitet werden!<br />
<br />
<pre><br />
batctl -m $batX gw_mode xxmbit/xxmbit<br />
</pre><br />
<br />
und dies für jedes batX Interface. Das Script muss daraufhin noch angepasst werden.<br />
<br />
<br />
auf den Routern kann der vorselektierte Gateway mit <br />
<br />
<code><br />
batctl gwl<br />
</code><br />
<br />
angeguckt werden. Ich vermute das der Gateway mit den Pfeil vorne der vorselektierte Gateway ist, allerdings machen erste beobachtete Daten bisher in meinen Augen noch keinen wirklichen Sinn.<br />
<br><br />
<br />
== DHCP Server ==<br />
Die DHCP Konfiguration kann schon mal vorbereitet werden, sollte aber erst mit als letzter Schritt scharf geschaltet werden. Ein DHCP-Server, der Clients nicht funktionierende DNS-Server oder ein nicht funktionierendes Gateway mitteilt, sperrt diese aus dem Freifunk Netz aus.<br />
<br />
In isc-dhcp-server definieren wir ...<br />
<code><br />
vi /etc/default/isc-dhcp-server<br />
</code><br />
<br />
... das der DHCP Server für das B.A.T.M.A.N Device Anfragen beantworten soll:<br />
<pre><br />
.<br />
.<br />
<br />
INTERFACES="bat0"<br />
.<br />
.<br />
</pre><br />
<br />
Nachfolge Konfiguration wird in auskommentierter Form vorbereitet und sollte erst im letzten Schritt durch Einkommentieren und durch einen Neustart des DHCP Servers...<br />
<code><br />
/etc/init.d/isc-dhcp-server restart<br />
</code><br />
...aktiviert werden.<br />
<br />
Die Konfiguration wird in dhcpd.conf vorgenommen:<br />
<code><br />
vi /etc/dhcp/dhcpd.conf<br />
</code><br />
<br />
und folgender Konfigurationsblock zunächst auskommentiert eingefügt, wobei Gateway und Hood spezifische Änderungen noch eingepflegt werden müssen:<br />
<pre><br />
.<br />
.<br />
.<br />
### Freifunk Franken<br />
#option domain-name "freifunk-franken.de";<br />
#option domain-name-servers 10.50.16.1;<br />
#authoritative;<br />
### Fuerth<br />
#subnet 10.50.32.0 netmask 255.255.248.0 { # Netzwerk und Netzmaske der Fuerther Hood<br />
# range 10.50.38.0 10.50.39.254; # IP-Range die der DHCP-Server innerhalb der Fuerther Hood verwaltet <br />
# option routers 10.50.32.5; # Default-Gateway, dass Clients mitgeteilt wird <br />
# option domain-name-servers 10.50.32.5, 10.50.32.1; # Name-Server, die Clients mitgeteilt werden<br />
#}<br />
</pre><br />
<br />
Netzwerk und Netzmaske müssen derjenigen der Hood des Gateways entsprechen. Im Beispiel ist dies Fürth, für z.B. Hassberge hieße der Eintrag "subnet 10.50.56.0 netmask 255.255.252.0".<br />
<br />
Der IP-Bereich (Range), die der DHCP-Server in der Hood verwaltet, wurde zuvor unter [[Portal:Netz]] reserviert.<br />
<br />
Unter Routers wird den Clients das Default-Gateway mitgeteilt: Das Gateway, über das Clients das Internet oder eine andere Hood erreichen. In unserem Beispiel routet das aufgesetzte Gateway selber via VPN ins Internet oder via olsr (später) in andere Hoods. Als Default-Gateway wird also die eigene statische IP des Gateways, aus der eigenen Hood, die in [[Portal:Netz]] reserviert wurde, verwendet.<br />
<br />
Ähnlich verhält es sich mit den Nameservern: Auf unserem Gateway wurde ein DNS Server eingerichtet, also kann der domain-name-server unser eigenes Gateway, mit der reservierten statische IP aus der Hood, wie in [[Portal:Netz]], sein. Als Backup empfiehlt sich ein weiterer DNS-Server aus der Hood, in unserem Beispiel ro1 in der Fürther.<br />
<br><br />
== GRE-Tunnel zu anderen Gateways ==<br />
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]].<br />
<br />
Der GRE-Tunnel wird in /etc/network/interfaces...<br />
<code><br />
vi /etc/network/interfaces<br />
</code><br />
<br />
...mit folgenden noch auf das Gateway anzupassenden Einträgen deklariert:<br />
<pre><br />
auto <tunnel><br />
iface <tunnel> inet static<br />
address <Eigene IPv4 (Freifunk Netz)><br />
pre-up ip -4 tunnel add $IFACE mode gre local <Eigene IPv4 (Internet)> remote <IPv4 des Tunnelpartners (Internet)> ttl 255<br />
#pre-up ip -6 tunnel add $IFACE mode ip6gre local <Eigene IPv6 (Internet)> remote <IPv6 des Tunnelpartners (Internet)> ttl 255<br />
<br />
up ifconfig $IFACE multicast<br />
pointopoint <IPv4 des Tunnelpartners (Freifunk Netz)><br />
post-up iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu<br />
post-up ip rule add iif $IFACE table fff<br />
post-up ip rule add from 10.50.0.0/16 table fff<br />
post-up ip rule add to 10.50.0.0/16 table fff<br />
post-down ip rule del iif $IFACE table fff<br />
post-down ip rule del from 10.50.0.0/16 table fff<br />
post-down ip rule del to 10.50.0.0/16 table fff<br />
post-down iptables -t mangle -D POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu<br />
post-down iptunnel del $IFACE<br />
</pre><br />
<br />
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.<br />
<br />
'''Beispiel:''' <br />
Um als fff-nue1 einen Tunnel zu ro1 aufzubauen, können die IP-Adressen wie folgt gewählt werden:<br />
<pre><br />
<tunnel> ro1<br />
<Eigene IPv4 (Freifunk Netz)> fff-nue1 10.50.252.1<br />
<IPv4 des Tunnelpartners (Freifunk Netz)> ro1 10.50.252.0<br />
<Eigene IPv4 (Internet)> fff-nue1 31.172.33.99<br />
<IPv4 des Tunnelpartners (Internet)> ro1 176.126.221.7<br />
</pre><br />
<br />
In der Partnerkonfiguration für ro1 werden die Rollen entsprechend vertauscht:<br />
<pre><br />
<tunnel> fff-nue1<br />
<Eigene IPv4 (Freifunk Netz)> ro1 10.50.252.0<br />
<IPv4 des Tunnelpartners (Freifunk Netz)> fff-nue1 10.50.252.1<br />
<Eigene IPv4 (Internet)> ro1 176.126.221.7<br />
<IPv4 des Tunnelpartners (Internet)> fff-nue1 31.172.33.99 <br />
</pre><br />
<br />
Der Tunnel kann über den Aufruf von<br />
<code><br />
ifup <tunnel><br />
</code><br />
...aufgebaut werden, wobei <tunnel> der Name des GRE-Interfaces ist (im Beispiel ro1)<br />
<br />
Nach Aufruf von ifconfig..<br />
<code><br />
ifconfig <br />
</code><br />
sollten wir einen Eintrag für den Tunnel (in diesem Beispiel ro1) vorfinden:<br />
<pre><br />
.<br />
.<br />
.<br />
ro1 Link encap:UNSPEC HWaddr B0-7B-1C-73-30-30-3A-35-00-00-00-00-00-00-00-00 <br />
inet addr:10.50.252.1 P-t-P:10.50.252.0 Mask:255.255.255.255<br />
inet6 addr: fe80::200:5efe:b07b:1c73/64 Scope:Link<br />
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1476 Metric:1<br />
RX packets:160913 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:146654 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0 <br />
RX bytes:66984353 (63.8 MiB) TX bytes:10675001 (10.1 MiB)<br />
.<br />
.<br />
.<br />
</pre><br />
<br><br />
== OLSR ==<br />
=== Basiskonfiguration ===<br />
Mittels OLSR können die Gateways selbstständig Routinginformationen austauschen. Ähnlich wie B.A.T.M.A.N einzelne Router innerhalb einer Hood vermesht (Level 2 Netz), handelt es sich bei olsr um ein mesh zwischen den Gateways (Level 3). Es ermöglicht ein Freifunk Franken internes Routing: z.B. kann eine beliebige IPv4 aus der Nürnberger Hood aus der Fürth Hood heraus erreicht werden.<br />
<br />
Vorlagen können unter Sicherung der Originaldateien wie folgt importiert werden:<br />
<code><br />
mv /etc/default/olsrd /etc/default/olsrd.orig<br />
<br />
mv /etc/olsrd/olsrd.conf /etc/olsrd/olsrd.conf.orig<br />
<br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd -P /etc/default/<br />
<br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/olsrd.conf -P /etc/olsrd/<br />
</code><br />
<br />
Zunächst zeigen wir die Interfaces an, unter dem wir olsr Routing Informationen austauschen:<br />
<code><br />
vi /etc/default/olsrd<br />
</code><br />
<br />
Im Beispiel wird über die 2 GRE-Tunnel nue1 und ro1 ausgetauscht, dies muss entsprechend der GRE-Tunnel Konfiguration angepasst werden: <br />
<pre><br />
.<br />
.<br />
#<br />
# Uncomment the next line run olsrd automatically at startup<br />
#<br />
START_OLSRD="YES"<br />
<br />
#<br />
# Uncomment the next line to force-configure the wifi interface to be setup<br />
# for ad-hoc mode using the /usr/sbin/olsrd-adhoc-setup script whenever olsrd<br />
# is started.<br />
#<br />
SETUP_ADHOC="NO"<br />
.<br />
.<br />
.<br />
#<br />
# Specify the network interfaces that olsrd will run on, this will most likely<br />
# be your wifi interface.<br />
#<br />
MESH_IF="nue1 ro1" <br />
.<br />
.<br />
</pre><br />
<br />
<br />
Weiter wird dann hier ...<br />
<code><br />
vi /etc/olsrd/olsrd.conf<br />
</code><br />
... konfiguriert. <br />
Da unser Beispiel-Gateway ins Netz der Fürther Hood eingebunden ist, teilen wir dies andern Gateways über den Eintrag 10.50.32.0/21 mit:<br />
<pre><br />
.<br />
.<br />
.<br />
# HNA IPv4 routes<br />
# syntax: netaddr netmask<br />
# Example Internet gateway:<br />
# 0.0.0.0 0.0.0.0<br />
<br />
Hna4<br />
{<br />
# Internet gateway:<br />
# 0.0.0.0 0.0.0.0<br />
# more entries can be added:<br />
# 192.168.1.0 255.255.255.0<br />
10.50.32.0/21<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Hier wird das olsr Webinterface auf port 8080 konfiguriert:<br />
<br />
<pre><br />
.<br />
.<br />
.<br />
LoadPlugin "olsrd_httpinfo.so.0.1"<br />
{<br />
# defaults to 1978<br />
PlParam "Port" "8080"<br />
# if you dont set these, the default is to listen only on the loopback device<br />
#PlParam "Host" "80.23.53.22"<br />
#PlParam "Net" "10.0.0.0 255.0.0.0"<br />
PlParam "Net" "0.0.0.0 0.0.0.0"<br />
#PlParam "Host" "127.0.0.1"<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Ferner wird der VPN-Tunnel (hier tun0) per persönlich angepasstem ping Kommando auf sein Funktion hin überwacht. Sollte der VPN-Tunnel ausfallen, ermöglicht olsr im Zusammenspiel mit der Routing Priorisierung (s.u) und der OpenVPN Start-/Stop Automatik (s.u.) ein automatisches Re-Routing:<br />
<pre><br />
.<br />
.<br />
.<br />
LoadPlugin "olsrd_dyn_gw.so.0.5"<br />
{<br />
# Here parameters are set to be sent to the<br />
# plugin. Theese are on the form "key" "value".<br />
# Parameters ofcause, differs from plugin to plugin.<br />
# Consult the documentation of your plugin for details.<br />
<br />
# Example: dyn_gw params<br />
<br />
# how often to check for Internet connectivity<br />
# defaults to 5 secs<br />
PlParam "Interval" "5"<br />
<br />
# if one or more IPv4 addresses are given, do a ping on these in<br />
# descending order to validate that there is not only an entry in<br />
# routing table, but also a real internet connection. If any of<br />
# these addresses could be pinged successfully, the test was<br />
# succesful, i.e. if the ping on the 1st address was successful,the<br />
# 2nd won't be pinged<br />
PlParam "Ping" "8.8.8.8"<br />
PlParam "Ping" "82.165.230.17"<br />
PlParam "pingcmd" "ping -c 1 -q -I tun0 %s"<br />
}<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Folgender Konfigurationsblock muss ans Ende der Konfigurationsdatei angefügt werden. Es ermöglich olsr die Manipulation der fff-Routingtabelle:<br />
<pre><br />
.<br />
.<br />
.<br />
# Specify the proto tag to be used for routes olsr inserts into kernel<br />
# currently only implemented for linux<br />
# valid values under linux are 1 .. 254<br />
# 1 gets remapped by olsrd to 0 UNSPECIFIED (1 is reserved for ICMP redirects)<br />
# 2 KERNEL routes (not very wise to use)<br />
# 3 BOOT (should in fact not be used by routing daemons)<br />
# 4 STATIC<br />
# 8 .. 15 various routing daemons (gated, zebra, bird, & co)<br />
# (defaults to 0 which gets replaced by an OS-specific default value<br />
# under linux 3 (BOOT) (for backward compatibility)<br />
#<br />
RtProto 8<br />
#<br />
# Specifies the routing Table olsr uses<br />
# RtTable is for host routes, RtTableDefault for the route to the default<br />
# internet gateway (2 in case of IPv6+NIIT) and RtTableTunnel is for<br />
# routes to the ipip tunnels, valid values are 1 to 254<br />
# There is a special parameter "auto" (choose default below)<br />
# (with smartgw: default is 254/223/224)<br />
# (without smartgw: default is 254/254/254, linux main table)<br />
#<br />
RtTable 10<br />
RtTableDefault 10<br />
RtTableTunnel 10<br />
#<br />
# Specifies the policy rule priorities for the three routing tables and<br />
# a special rule for smartgateway routing (see README-Olsr-Extensions)<br />
# Priorities can only be set if three different routing tables are set.<br />
# if set the values must obey to condition<br />
# RtTablePriority < RtTableDefaultOlsrPriority<br />
# < RtTableTunnelPriority < RtTableDefaultPriority.<br />
# There are two special parameters, "auto" (choose fitting to SmartGW<br />
# mode) and "none" (do not set policy rule)<br />
# (with smartgw: default is none/32776/32776/32796)<br />
# (without smartgw: default is none/none/none/none)<br />
#<br />
# RtTablePriority auto<br />
# RtTableDefaultOlsrPriority auto<br />
# RtTableTunnelPriority auto<br />
# RtTableDefaultPriority auto<br />
</pre><br />
<br />
<br />
Das Freifunk Franken intere Routing kann nun getestet werden.<br />
<br />
Zunächst einmal starten wir olsr neu:<br />
<code><br />
/etc/init.d/olsrd restart<br />
</code><br />
<br />
<br />
Die Routinginformationen des olsr-meshes sollten in der fff-Routingtabelle auftauchen:<br />
<code><br />
ip route show table fff<br />
</code><br />
<br />
Exemplarischer Auszug:<br />
<pre><br />
.<br />
.<br />
.<br />
10.50.32.1 via 10.50.32.1 dev ro1 proto gated metric 2 onlink <br />
10.50.32.2 via 10.50.32.2 dev nue1 proto gated metric 2 onlink <br />
10.50.40.0/21 via 10.50.32.1 dev ro1 proto gated metric 2 onlink <br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Eine IP4 aus der Nürnberger Hood (10.50.40.0/21) sollte z.B. von Fürth aus (10.50.32.0/21) erreichbar sein:<br />
<br />
<code><br />
ping 10.50.40.3<br />
</code><br />
<br />
Antwort:<br />
<pre><br />
PING 10.50.40.3 (10.50.40.3) 56(84) bytes of data.<br />
64 bytes from 10.50.40.3: icmp_seq=1 ttl=63 time=42.2 ms<br />
64 bytes from 10.50.40.3: icmp_seq=2 ttl=63 time=42.7 ms<br />
^C<br />
--- 10.50.40.3 ping statistics ---<br />
2 packets transmitted, 2 received, 0% packet loss, time 1000ms<br />
rtt min/avg/max/mdev = 42.279/42.516/42.753/0.237 ms<br />
</pre><br />
<br><br />
=== OpenVPN Start/Stop Automatik ===<br />
OLSR testet mit dem Dynamic Gateway Plugin, ob die Default Route über den OpenVPN Tunnel noch funktioniert, indem regelmässig teilweise mehrere verschiedene Ziele über den Tunnel angepingt werden. Sollte der OpenVPN Tunnel nicht mehr funktionieren, baut OLSR eine neue Default-Route zu einem anderem Gateway auf, über das dann der Internet-Traffic läuft. Beide Default-Routen, die über den OpenVPN Tunnel und die von OLSR, existieren parallel, wobei zunächst weiterhin die OpenVPN Verbindung verwendet wird.<br />
<br />
Da die OpenVPN Verbindung ausgefallen ist, aber trotzdem noch als bevorzugte Default-Route eingetragen ist, ist die Internetanbindung bis die Störung VPN-Server seitig behoben ist, trotzdem nicht verfügbar. <br />
<br />
Für diesen Anwendungsfall wird ein Skript vorgeschlagen, dass die Funktion des OpenVPN Tunnels überwacht und den Tunnel (und die OpenVPN Default-Route) bei Nicht-Funktion abbaut. Um die Funktion zu überprüfen werden in regelmässigen Abständen 2 verschiedene Ziele über den Tunnel angepingt. Scheitert dies, wird der Tunnel für einen gewissen Zeitraum abgebaut, in dem dann stattdessen das OLSR Dynamic Gateway Plugin das Routing übernimmt. Danach wird die Verbindung wieder aufgebaut. Anschliessend wird überprüft, ob der OpenVPN-Tunnel wieder funktioniert. Tut er es nicht, wird er wieder abbgebaut, funktioniert er, bleibt er bis zur Detektion der nächsten Störung als Internetanbindung erhalten.<br />
<br />
Man importiert die Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/auto_start-stop_ovpn.sh -P /usr/local/bin/<br />
</code><br />
<br />
Alternativ kann man statt der Vorlage auch eine leere Datei anlegen:<br />
<code><br />
touch /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
Man macht das Skript ausführbar:<br />
<code><br />
chmod +x /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
<br />
Nun öffnet man die Datei im Editor ...<br />
<code><br />
vi /usr/local/bin/auto_start-stop_ovpn.sh<br />
</code><br />
<br />
... und füllt sie mit Inhalt oder editiert den importierten Inhalt:<br />
<pre><br />
#!/bin/bash<br />
IF="tun0" # Interface used for ping<br />
ping1_target="8.8.8.8" # IP no. 1 used for ping<br />
ping2_target="82.165.229.31" # IP no. 2 used for ping<br />
ping_interval="5" # waiting time in-between two pings<br />
switchback_interval="3600" # waiting time for interface to recover before probing again<br />
start_grace="10" # waiting time to allow for tunnel restart<br />
logfile="/dev/null" # logfile for debug<br />
<br />
openvpn_stop-cmd () { # command used disabling tunnel<br />
#service openvpn stop # ubuntu<br />
/etc/init.d/openvpn stop # debian<br />
#killall openvpn # hardcore<br />
}<br />
<br />
openvpn_start-cmd () { # command used enabling tunnel<br />
#service openvpn start # ubuntu<br />
/etc/init.d/openvpn start # debian<br />
#openvpn /etc/openvpn/*.conf & # hardcore<br />
}<br />
<br />
ping1 () {<br />
echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF" &>> $logfile<br />
ping -q -c 3 -i ${ping_interval} ${ping1_target} -I $IF &>> $logfile<br />
ping1_ExitCode=$?<br />
echo "$(date): Exit Status: ${ping1_ExitCode}" &>> $logfile<br />
}<br />
<br />
ping2 () {<br />
echo "$(date): ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF" &>> $logfile<br />
ping -q -c 3 -i ${ping_interval} ${ping2_target} -I $IF &>> $logfile<br />
ping2_ExitCode=$?<br />
echo "$(date): Exit Status: ${ping2_ExitCode}" &>> $logfile<br />
}<br />
<br />
<br />
while true<br />
do<br />
# wait for interface build-up, if interface not present<br />
if [ ! -h "/sys/class/net/$IF" ]; then<br />
echo "$(date): Interface $IF not detected. Waiting ${start_grace} seconds." &>> $logfile<br />
sleep ${start_grace}<br />
fi<br />
<br />
# perform ping<br />
ping1<br />
ping2<br />
<br />
# check if ping successful<br />
if ([[ ${ping1_ExitCode} -eq 0 ]] || [[ ${ping2_ExitCode} -eq 0 ]]); then<br />
sleep ${ping_interval}<br />
else<br />
logger -t "$0" ${ping1_target} and ${ping2_target} not reached via interface $IF.<br />
echo "$(date): ${ping1_target} and ${ping2_target} not reached via interface $IF." &>> $logfile<br />
<br />
if [ -h "/sys/class/net/$IF" ]; then<br />
logger -t "$0" Stopping interface $IF.<br />
echo "$(date): Stopping interface $IF." &>> $logfile<br />
openvpn_stop-cmd &>> $logfile<br />
fi<br />
<br />
sleep ${switchback_interval}<br />
<br />
if [ ! -h "/sys/class/net/$IF" ]; then<br />
logger -t "$0" Restoring interface $IF to probe for recovery.<br />
echo "$(date): Restoring interface $IF to probe for recovery." &>> $logfile<br />
openvpn_start-cmd &>> $logfile<br />
fi<br />
fi<br />
done<br />
</pre><br />
<br />
Hierbei können im Skript folgende Anpassungen vorgenommen werden:<br />
*openvpn_stop-cmd: Der Befehl, mit dem der OpenVPN Tunnel '''abgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ als Prozess gekillt werden.<br />
*openvpn_start-cmd: Der Befehl, mit dem der OpenVPN tunnel '''aufgebaut''' wird. Sollte dies auf dem normalen Weg nicht funktionieren, kann er alternativ per openvpn Kommandozeilenaufruf gestartet werden.<br />
*IF: Das OpenVPN Tunnel Device. Normalerweise ist das tun0.<br />
*ping1_target,ping2_target: Die IP-Adressen die über das Tunnel-Interface IF angepingt werden, um den Tunnel auf Funktion zu überprüfen. Vorauswahl: Google DNS und Web.de<br />
*ping_interval: Der zeitliche Anstand zwischen zwei Ping-Versuchen. Vorauswahl: 5 Sekunden.<br />
*switchback_interval: Der Zeitraum, den der Tunnel abgebaut bleibt, sollte er als nicht-funktionierend erkannt worden sein. Es wird ein träges Verhalten empfohlen. Vorauswahl: 3600 Sekunden.<br />
*start_grace: Der Zeitraum, der dem Tunnel zum Starten eingeräumt wird. Die Timer-Funktion macht ferner das Skript gegen Restarts des Tunnels unempfindlich.<br />
*logfile: Für Debug Zwecke kann man detaillierte Ausgaben hier in eine Datei umleiten.<br />
<br />
Das Skript selber kann manuell ...<br />
<code><br />
auto_start-stop_ovpn.sh &<br />
</code><br />
<br />
...und bei jedem Systemstart mit gestartet werden, indem es z.B. in /etc/rc.local ...<br />
<code><br />
vi /etc/rc.local<br />
</code><br />
<br />
...wie folgt eingetragen wird:<br />
<pre><br />
.<br />
.<br />
.<br />
#enable tunnel monitoring with 60 seconds delay<br />
(sleep 60; auto_start-stop_ovpn.sh &) &<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
<br />
Getestet werden kann das Skript z.B., indem man sich alle Default-Routen der fff-Tabelle anzeigen lässt: <br />
<code><br />
watch "ip route show table fff | grep default"<br />
</code><br />
<br />
und parallel dazu auf einer zweiten Shell das openvpn deaktiviert:<br />
<code><br />
killall openvpn<br />
</code><br />
<br />
Es sollte eine neue Default-Route zu einem anderen Gateway aufgebaut werden, über die der Internet-Traffic dann läuft. Die Route über den OpenVPN Tunnel sollte verschwinden. Nach der eingestellten Zeit wird der OpenVPN Tunnel durch das Skript wieder reaktiviert. Danach existieren beide Default-Routen parallel, bis OLSR seine Route automatisch wieder abbaut. Die OpenVPN Default-Route bleibt und ist wieder aktiv.<br />
<br><br />
=== Priorisieren von OLSR Routen ===<br />
OLSR erstellt die fff-Routingtabelle selbstständig, indem es die Linkqualität anhand von Algorithmen bewertet. Diese Bewertung ist recht volatil, was dazu führen kann, das die von OLSR ausgesuchte Default-Route häufig wechselt. Für die verbundenen Clients wechselt jedes mal die externe Internet IP mit, je nachdem über welches Gateway OLSR den Internet-Traffic gerade abwirft. Bei IP-Wechsel stoppen z.B. Downloads aus dem Internet, stoppen Videos im Abspielen, werden ssh Verbindungen gekappt.<br />
<br />
Um diese Dynamik nicht allzu schnell zu gestalten, empfiehlt es sich OLSR eine oder zwei Default-Routen mitzuteilen, die bevorzugt verwendet werden. Zusätzlich wird NatThreshold, einen Schwellwert den die neue Default-Route besser sein muss als die alte, bevor gewechselt wird, definiert.<br />
<br />
Dies geschieht über Gewichtungsfaktoren in olsrd.conf:<br />
<br />
<code><br />
vi /etc/olsrd/olsrd.conf<br />
</code><br />
<br />
Routen kann man im Abschnitt InterfaceDefaults priorisieren. <br />
Hier können Gewichtungsfaktoren für die GRE-Tunnel zu anderen Gateways eingeführt werden, mit denen die Link-Qualität beeinflusst werden kann:<br />
<pre><br />
.<br />
.<br />
.<br />
# If a certain route should be preferred<br />
# or ignored by the mesh, the Link Quality<br />
# value of a node can be multiplied with a factor<br />
# entered here. In the example the route<br />
# using 192.168.0.1 would rather be ignored.<br />
# A multiplier of 0.5 will result in a small<br />
# (bad) LinkQuality value and a high (bad)<br />
# ETX value.<br />
<br />
# preferred link<br />
LinkQualityMult <tunnel1_ip> 0.99<br />
<br />
# preferred link<br />
LinkQualityMult <tunnel2_ip> 0.99<br />
<br />
# This multiplier applies to all other nodes<br />
LinkQualityMult default 0.7<br />
.<br />
.<br />
.<br />
</pre><br />
<br />
Im Beispiel werden alle Routen herabgestuft (Faktor 0.7), mit der Ausnahme derer die über <tunnel1_ip> oder <tunnel2_ip> laufen (Faktor 0.99). <tunnel_ip1> sind dabei die Point-to-Point Partner IPs der GRE Tunnel der jeweiligen Gateways im Freifunk Netz. Die nicht herabgestuften Routen können analog als priorisiert betrachtet werden. Für eine Priorisierung der Route von nue1 zu ro1 wäre die <tunnel1/2_ip> z.B. die 10.50.252.1 (Vgl. [[Portal:Netz]]).<br />
<br />
NatThreshold wird im Hauptabschnitt von olsrd.conf definiert:<br />
<pre><br />
.<br />
.<br />
# If the NAT-Endpoint (the preferred 0/0 HNA emitting node)<br />
# is to be changed, the ETX value of the current 0/0 is<br />
# multiplied with the NatThreshold value before being<br />
# compared to the new one<br />
# The parameter can be a value between 0.1 and 1.0, but<br />
# should be close to 1.0 if changed.<br />
<br />
NatThreshold 0.7<br />
.<br />
.<br />
</pre><br />
<br />
Im Beispiel muss die Linkqualität der neuen Default-Route um 30% besser bewertet als die aktuelle sein, bevor die Default-Route gewechselt wird.<br />
<br />
Die Änderungen werden nach Neustart von OLSR aktiv:<br />
<code><br />
/etc/init.d/olsrd restart<br />
</code><br />
<br><br />
= Einbringen des Gateways in die Hood / Keyserver =<br />
Abschliessend muss das Gateway im Keyserver als Gateway der entsprechenden Hood eingetragen werden. Hierfür benötigt man einen Keyserver-Administrator => [[Server]].<br />
<br />
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.<br />
<br />
Der DHCP-Server sollte als letzter Schritt aktiviert werden (s.o.)<br />
<br><br />
= Transparent Proxy =<br />
Auf dem Gateway kann (aber muss nicht) ein Proxy-Server installiert werden, der Dateien (z.B. Bilder), die schon mal angefragt wurden, nicht aus dem Internet holt, sondern als "lokal" gespeicherte Datei direkt vom Gateway bereitstellt. Die Clients werden dabei über den Proxy gezwungen, d.h. das Gateway leitet die Anfragen pauschal an den Proxy weiter, welcher entscheidet ob der die Anfrage selber bedient oder Gateway-extern anfragt. <br />
<br />
Die Einrichtung eines Proxys ist '''optional''', d.h. der Proxy ist für die Funktion des Gateways nicht notwendig. Proxy-Server reduzieren Antwortzeiten und Traffic für sich '''häufig''' wiederholende Anfragen (z.B. Spiegel Online, Windows Update).<br />
<br />
'''Hinweis''': <br />
Die Einrichtung eines Proxy ist umstritten, da:<br />
* HTTP-Header, wenn auch in geringem Umfang, verändert werden<br />
* Daten, wenn auch nicht direkt einsehbar, auf dem Gateway gespeichert werden<br />
* Daten nicht unmittelbar von der Originalquelle bezogen werden <br />
* Die Effizienzsteigerung gering ist. Nach Auswertung werden ca. 7% aller unverschlüsselten HTTP-Anfragen von dem Gateway direkt beantwortet. Für diese 7% halbiert sich der benötigte Traffic, wobei ein Großteil aller Webseiten heutzutage verschlüsselt wird und z.Zt. 50% des benötigten Traffics Overhead ist. <br />
* Zusätzliche Ressourcen (RAM, Prozessor) auf dem Gateway benötigt werden <br />
<br />
'''Inkompatiblität''': Die Konfiguration funktioniert z.Zt. nicht im Zusammenspiel mit der "OpenVPN Start/Stop Automatik" und dem automatischen OLSR Re-Routing des Default-Gateways (Dynamic Gateway Plugin).<br />
<br><br />
== Installation ==<br />
Installiert wird der de-facto-Standard squid:<br />
<code><br />
apt-get install squid3<br />
</code><br />
<br />
Für die kommende Konfiguration stoppen wir squid wieder:<br />
<code><br />
/etc/init.d/squid3 stop<br />
</code><br />
<br><br />
== Konfiguration ==<br />
Die mit installiere Konfigurationsdatei squid.conf ist sehr umfangreich und bietet eine gute Dokumentationsbasis, ist damit aber auch etwas unhandlich.<br />
<br />
Aus diesem Grund empfiehlt es sich, die Datei umzubenennen:<br />
<code><br />
mv /etc/squid3/squid.conf /etc/squid3/squid.conf.orig<br />
</code><br />
<br />
Wir importieren die Datei von einer Vorlage:<br />
<code><br />
wget https://raw.githubusercontent.com/FreifunkFranken/configs/master/squid.conf -P /etc/squid3/<br />
</code><br />
<br />
Alternativ können wir die Datei auch leer erstellen:<br />
<code><br />
touch /etc/squid3/squid.conf<br />
</code><br />
<br />
Danach öffnen wir die Konfigurationsdatei...<br />
<code><br />
vi /etc/squid3/squid.conf<br />
</code><br />
<br />
...und füllen diese mit Inhalt, der allerdings noch auf das Gateway angepasst werden muss:<br />
<pre> <br />
# cache size in MB / no. of subdirectories / no. of subsubdirectories<br />
cache_dir ufs /var/spool/squid3 100 16 256<br />
<br />
#maximum object size in cache (default: 4 MB)<br />
#maximum_object_size 128 MB<br />
maximum_object_size 4 MB<br />
<br />
# Memory used for caching<br />
cache_mem 32 MB<br />
<br />
# No access log<br />
#access_log /var/log/squid3/access.log combined<br />
access_log none<br />
<br />
# Hostname shown in messages<br />
visible_hostname fff<br />
<br />
# Bind Squid to port ... and configure as transparent proxy <br />
http_port 3128 intercept<br />
# In addition a forward proxy is required<br />
http_port 3129<br />
<br />
refresh_pattern ^ftp: 1440 20% 10080<br />
refresh_pattern ^gopher: 1440 0% 1440<br />
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0<br />
refresh_pattern . 0 20% 4320<br />
<br />
# Allow connects from Freifunk Franken network<br />
acl fff src 10.50.0.0/16 <br />
<br />
# DNS by Freifunk-IP of localhost and Google DNS<br />
dns_nameservers 10.50.32.5 8.8.8.8<br />
<br />
# Bind outgoing address to Freifunk-Server IP to allow for VPN Routing <br />
tcp_outgoing_address 10.50.32.5<br />
udp_outgoing_address 10.50.32.5<br />
<br />
# Privacy options <br />
via off<br />
forwarded_for delete<br />
<br />
# standard http anonymizer<br />
request_header_access From deny all<br />
#request_header_access Referer deny all<br />
#request_header_access User-Agent deny all<br />
<br />
## paranoid http anonymizer<br />
#request_header_access Authorization allow all<br />
#request_header_access Proxy-Authorization allow all<br />
#request_header_access Cache-Control allow all<br />
#request_header_access Content-Length allow all<br />
#request_header_access Content-Type allow all<br />
#request_header_access Date allow all<br />
#request_header_access Host allow all<br />
#request_header_access If-Modified-Since allow all<br />
#request_header_access Pragma allow all<br />
#request_header_access Accept allow all<br />
#request_header_access Accept-Charset allow all<br />
#request_header_access Accept-Encoding allow all<br />
#request_header_access Accept-Language allow all<br />
#request_header_access Connection allow all<br />
#request_header_access All deny all<br />
<br />
# Access controls<br />
acl SSL_ports port 443 # https<br />
acl Safe_ports port 80 # http<br />
acl Safe_ports port 21 # ftp<br />
acl Safe_ports port 443 # https<br />
acl Safe_ports port 70 # gopher<br />
acl Safe_ports port 210 # wais<br />
acl Safe_ports port 1025-65535 # unregistered ports<br />
acl Safe_ports port 280 # http-mgmt<br />
acl Safe_ports port 488 # gss-http<br />
acl Safe_ports port 591 # filemaker<br />
acl Safe_ports port 777 # multiling http<br />
<br />
acl CONNECT method CONNECT<br />
http_access deny !Safe_ports<br />
http_access deny CONNECT !SSL_ports<br />
http_access allow localhost manager<br />
http_access deny manager<br />
http_access allow fff<br />
http_access allow localhost<br />
http_access deny all<br />
</pre><br />
<br />
Hier '''müssen''' angepasst werden:<br />
* cache_dir: Die Gesamtgröße des Caches (hier: 100 MByte) muss so bemessen sein, dass auf der Partition auch bei Maximalgröße des Caches noch Speicher frei bleibt. Squid Standardeinstellung ist 100 MB bei 16 Verzeichnissen und jeweils 256 Unterverzeichnissen. Freier Speicherplatz kann mit "df -h" ermittelt werden.<br />
* dns_nameservers: Hier sollten die '''Freifunk-IPv4''' des Gateways (in diesem Beispiel 10.50.32.5) und eine externe IP (hier Google DNS 8.8.8.8) eingetragen werden. Wichtig ist, '''nicht localhost''' einzutragen, da die Anfrage im Zusammenspiel mit der "outgoing address" (s.u.) über die fff-Routingtabelle laufen muss.<br />
* tcp_outgoing_address und udp_outgoing_address: Diese beide Einträge sind elementar wichtig. Zwar funktioniert der Proxy auch ohne, routet aber nicht über das VPN sondern direkt vom Gateway ins Internet. Damit die fff-Routingtabelle verwendet wird, für die als Default-Gateway eine VPN Verbindung eingerichtet ist, tragen wir hier die Freifunk-IP des Gateways ein (10.50.<irgendwas>). In diesem Beispiel ist die Freifunk-IPv4 des Gateways die 10.50.32.5.<br />
* access_log: Das Access log sollte deaktiviert bleiben (access_log none), da es ein lebendiges Beispiel für Vorratsdatenspeicherung ist und die log-Dateien auch sehr schnell, sehr groß werden.<br />
<br />
Danach erstellen wir die Verzeichnisstruktur des Proxy:<br />
<code><br />
squid3 -z<br />
</code><br />
<br />
Jetzt sind wir fast fertig. Wir starten den Proxy:<br />
<code><br />
/etc/init.d/squid3 start<br />
</code><br />
<br />
Anfragen, die auf Port 80 (http) reinkommen, müssen nun noch auf Port 3128 umgeleitet werden. Auf Port 3128 lauscht unser Proxy, http-Anfragen werden quasi transparent (oder zwangsweise) über den Proxy geleitet :<br />
<code><br />
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
</code><br />
<br />
Damit unsere Portumleitung mit jedem Start von Squid eingerichtet und mit jedem Stopp aufgehoben wird, pflegen wir sie (nicht ganz sauber) im squid start/stop Skript mit ein:<br />
<code><br />
vi /etc/init.d/squid3<br />
</code><br />
<br />
und fügen '''zwei''' iptables Einträge nach dem Start und vor dem Stopp von Squid ein:<br />
<pre><br />
.<br />
.<br />
.<br />
start () {<br />
cache_dir=`find_cache_dir cache_dir`<br />
cache_type=`grepconf cache_dir`<br />
<br />
#<br />
# Create run dir (needed for several workers on SMP)<br />
#<br />
create_run_dir<br />
<br />
#<br />
# Create spool dirs if they don't exist.<br />
#<br />
if test -d "$cache_dir" -a ! -d "$cache_dir/00"<br />
then<br />
log_warning_msg "Creating $DESC cache structure"<br />
$DAEMON -z -f $CONFIG<br />
fi<br />
<br />
umask 027<br />
ulimit -n 65535<br />
cd $cache_dir<br />
start-stop-daemon --quiet --start \<br />
--pidfile $PIDFILE \<br />
--exec $DAEMON -- $SQUID_ARGS < /dev/null<br />
# Use as transparent proxy<br />
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
return $?<br />
}<br />
<br />
stop () {<br />
PID=`cat $PIDFILE 2>/dev/null`<br />
# Use as transparent proxy<br />
iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128<br />
start-stop-daemon --stop --quiet --pidfile $PIDFILE --exec $DAEMON <br />
#<br />
# Now we have to wait until squid has _really_ stopped.<br />
#<br />
.<br />
.<br />
.<br />
</pre></div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Portal:Netz&diff=5254
Portal:Netz
2016-01-02T16:34:59Z
<p>Green: /* Statische IP-Adressen */</p>
<hr />
<div>== Das Netz ==<br />
Eine Karte der aktiven Router gibt es [https://netmon.freifunk-franken.de/map.php hier].<br />
<br />
Eine Karte der Hoods ist [http://keyserver.freifunk-franken.de/fff/voronoimap.php hier] zu finden.<br />
<br />
Die [https://netmon.freifunk-franken.de/routerlist.php Liste der Router] kann dank Netmon immer live verfolgt werden. Infos über die Schreibweise (z.B. "/20") gibt es in der [http://de.wikipedia.org/wiki/CIDR Wikipedia].<br />
<br />
=== Gateway ===<br />
Erste Versuche einer sinnvollen Aufteilung von Gateways. Erweiterungen und Verbesserungen sind jederzeit erwünscht. [https://pad.freifunk.net/p/Gatewayaufteilung-Franken Zum Pad]<br />
<br />
== IP-Netz ==<br />
Mit der Netz-Umstellung vom 22.03.2014 haben wir nicht mehr länger ein großes [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_2_.E2.80.93_Sicherungsschicht_.28Data_Link_Layer.29 Layer-II-Netz], welches durch das [https://de.wikipedia.org/wiki/B.A.T.M.A.N. B.A.T.M.A.N. advanced]-Protokoll geroutet wird. Seitdem gibt es mehrere [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_3_.E2.80.93_Vermittlungsschicht_.28Network_Layer.29 Layer-III-Netze] (Hoods). Ein Layer-III-Netz entsteht grundsätzlich, indem hier ein Subnetz eingetragen wird. Wie dabei genau vorgegangen wird, steht in [[HoodVerwaltung]].<br />
Für jedes Subnetz muss separat abgewogen werden, wie groß es werden wird und wo es dann in die bestehenden Subnetze am besten eingegliedert werden kann.<br />
<br />
==== DHCP ====<br />
[[Datei:Hoods.png|200px|thumb|right|Vorschlag für die Hood-Organisation]]<br />
Damit simple Clients das neue Subnetz nutzen können, muss ein eigener DHCP-Server pro Subnetz bereit gestellt werden. Es macht dabei häufig Sinn, das Subnetz in IP-Bereiche aufzuteilen, die von mehreren DHCP-Servern verteilt werden. Ein zweiter DHCP-Server ermöglicht zum einen eine Lastverteilung, zum anderen erhöht sich die Ausfallsicherheit. Der DHCP-Server muss den Clients ein Default-Gateway und mindestens einen DNS-Server zuweisen. Da das Default-Gateway ebenfalls innerhalb des Subnetzes liegen muss, bietet es sich an, den selben Server, auf dem das DHCP läuft, zu nutzen.<br />
<br />
==== OLSR-Router ====<br />
Das Subnetz muss anschließend an das vorhandene Freifunknetz angeschlossen werden. Dazu muss eine Verbindung zu einem bestehenden OLSR-Router aufgebaut werden. Dies kann eine VPN-Verbindung, aber auch eine Wifi-Verbindung sein und muss individuell zwischen den zwei Parteien ausgehandelt werden. Es kann sinnvoll sein, Verbindungen zu mehr als einem OLSR-Router zu haben. Sobald der eigene Router an das OLSR-Netz angebunden ist, ist er selbst ein OLSR-Router.<br />
<br />
An den eigenen OLSR-Router können nun Accesspoints angeschlossen werden. Dies kann per VPN, WLAN, Kabel oder anderweitig geschehen. Es ist auch möglich, den Accesspoint selbst als OLSR-Router anzubinden. Auch diese Konfiguration ist individuell zu klären. Ein Accesspoint kann ein (oder mehrere) einfacher Wifi-AP oder auch ein Array von mehreren B.A.T.M.A.N.-Knoten sein. Es sollte vermieden werden, dass sich Subnetze vermischen. Dies würde immer dann passieren, wenn zwei Layer-II-Netze, die eigentlich unterschiedliche Subnetze verteilen, verbunden werden. Besonders beim B.A.T.M.A.N.-Protokoll besteht hier leicht diese Gefahr; daher sollte für jedes Subnetz eine eigene BSSID und ESSID gewählt werden.<br />
<br />
==== Aus Routersicht ====<br />
Nur Router in einer Hood können sich per B.A.T.M.A.N. advanced vermaschen, sowohl per VPN, also auch per WLAN. Daher müssen Router die räumlich nahe beieinander stehen auch in derselben Hood sein. Durch das Vermaschen des Netzes wird allerdings auch Verwaltungs-Verkehr erzeugt (Overhead). Je größer die Hood, desto größer der Overhead.<br />
<br />
Eine Verbindung zwischen Routern in unterschiedlichen Hoods ist per IP (OSI Schicht 3) möglich.<br />
<br />
Wenn im Netmon kein Standort eingegeben wurde, dann landet der Router in der Dafault-Hood.<br />
<br />
==== Monitoring (Netmon) ====<br />
Aktuell können sich Knoten nur über ein IPv6-Link-Local-Interface beim Netmon anmelden und Netmon kann die Knoten nur über eine IPv6-Link-Local-Adresse abfragen. Hier muss ein neuer Mechanismus gefunden werden, der es ermöglicht, die Knoten über Subnetze hinweg anzusprechen.<br />
<br />
Als Workaround ist es möglich, über einen Layer-II-Tunnel zum Netmon-Server das Subnetz an das Netmon anzubinden. Auf dem Netmon-Server werden alle Subnetze in einem Bridge-Interface zusammengefasst, welches keine Pakete weiterleiten kann.<br />
<br />
==== Wireless-LAN ====<br />
Wir haben uns auf folgende WLAN-Parameter verständigt:<br />
'''ESSID: franken.freifunk.net'''. Kanal 1.<br />
<br />
== Liste der Subnetze ==<br />
{|<br />
! !! Bereich !! Bereitgestellt durch<br />
|-<br />
! 10.50.0.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.0.1 – 10.50.15.254</font> || <br />
|-<br />
! 10.50.16.0/20 || Default Hood ||<br />
|-<br />
| || 10.50.16.1 – 10.50.17.255 || Statische Adressen<br />
|-<br />
| || 10.50.18.0 – 10.50.19.255 || --<br />
|-<br />
| || 10.50.20.0 – 10.50.21.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey">10.50.22.0 – 10.50.23.254 </font> || <br />
|-<br />
| || <font color="grey">10.50.24.0 – 10.50.31.254 </font> || <br />
|-<br />
! 10.50.32.0/21 || Fürth Hood ||<br />
|-<br />
| || 10.50.32.1 – 10.50.32.255 || Statische Adressen<br />
|-<br />
| || 10.50.33.0 – 10.50.34.255 || --<br />
|-<br />
| || 10.50.35.0 – 10.50.36.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.37.0 – 10.50.37.255 || [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || 10.50.38.0 – 10.50.39.254 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.40.0/21 || Nürnberg Hood ||<br />
|-<br />
| || 10.50.40.1 – 10.50.40.255 || Statische Adressen<br />
|-<br />
| || 10.50.41.0 – 10.50.42.255 || [[Server#FFF-GW-M1|FFF-GW-M1]]<br />
|-<br />
| || <font color="grey"> 10.50.43.0 - 10.50.43.255 </font> || <br />
|-<br />
| || 10.50.44.0 – 10.50.44.255 || (umgezogen) [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| ||10.50.45.0 – 10.50.46.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.47.0 – 10.50.47.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.48.0/21 || Ansbach Hood ||<br />
|-<br />
| || 10.50.48.1 – 10.50.48.255 || Statische Adressen<br />
|-<br />
| || 10.50.49.0 – 10.50.50.255 || <br />
|-<br />
| || 10.50.51.0 – 10.50.52.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.53.0 – 10.50.54.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| || <font color="grey">10.50.55.0 – 10.50.55.254</font> || <br />
|-<br />
! 10.50.56.0/22 || Hassberge Hood ||<br />
|-<br />
| || 10.50.56.1 – 10.50.56.255 || Statische Adressen<br />
|-<br />
| || 10.50.57.0 – 10.50.57.255 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
| || 10.50.58.0 – 10.50.58.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.59.0 – 10.50.59.254 || [[Server#fff-has|fff-has]]<br />
|-<br />
! 10.50.60.0/22 || HassbergeSued Hood ||<br />
|-<br />
| || 10.50.60.1 – 10.50.60.255 || Statische Adressen<br />
|-<br />
| || 10.50.61.0 – 10.50.61.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
| || 10.50.62.0 – 10.50.62.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.63.0 – 10.50.63.254 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
! 10.50.64.0/21 || Erlangen Hood ||<br />
|-<br />
| || 10.50.64.1 – 10.50.64.255 || Statische Adressen<br />
|-<br />
| || 10.50.65.0 – 10.50.66.255 || [[Server#fff-gw-kwadro|fff-gw-kwadro]]<br />
|-<br />
| || 10.50.67.0 – 10.50.68.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.69.0 – 10.50.71.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.72.0/21 || Würzburg Hood ||<br />
|-<br />
| || 10.50.72.1 – 10.50.72.255 || Statische Adressen<br />
|-<br />
| || <font color="grey"> 10.50.73.0 – 10.50.74.255 </font>|| <br />
|-<br />
| || 10.50.75.0 – 10.50.76.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.77.0 – 10.50.77.255 || [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || <font color="grey"> 10.50.78.0 – 10.50.78.255 </font>|| <br />
|-<br />
| || 10.50.79.0 – 10.50.79.254 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
! 10.50.80.0/21 || BGL ||<br />
|-<br />
| || 10.50.80.1 – 10.50.80.255 || Statische Adressen<br />
|-<br />
| || 10.50.81.0 – 10.50.82.255 || [[Server#watzmann|watzmann]]<br />
|-<br />
| || 10.50.83.0 – 10.50.84.255 || [[Server#staufen|staufen]]<br />
|-<br />
! 10.50.88.0/21 || NbgLand Hood ||<br />
|-<br />
| || 10.50.88.1 – 10.50.88.255 || Statische Adressen<br />
|-<br />
| || 10.50.89.0 – 10.50.89.255 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| || <font color="grey">10.50.90.0 - 10.50.93.255</font> || <br />
|-<br />
| || 10.50.94.0 – 10.50.95.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.96.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.96.1 – 10.50.127.254</font> || <br />
|-<br />
! 10.50.128.0/24 || Test von Casandro ||<br />
|-<br />
| || 10.50.128.20 – 10.50.128.200 || 10.50.128.1<br />
|-<br />
! 10.50.129.0/24 || free ||<br />
|-<br />
| || || <br />
|-<br />
! 10.50.130.0/24 || free ||<br />
|-<br />
| || <font color="black">10.50.130.1 – 10.50.130.254</font> || Testbereich ChristianD für [https://wiki.freifunk-franken.de/w/Standorte/Fuerth/Unterfuerberg/L3Konzept Konzept Unterfürberg]<br />
|-<br />
! 10.50.131.0/24 || free ||<br />
|-<br />
| || <font color="grey">10.50.131.1 – 10.50.131.254</font> || <br />
|-<br />
! 10.50.132.0/22 || border:none gateway ||<br />
|-<br />
| || 10.50.132.1 – 10.50.132.255 || Statische Adressen<br />
|-<br />
| || 10.50.133.0 – 10.50.134.255 || DHCP<br />
|-<br />
| || <font color="grey">10.50.135.0 – 10.50.135.254</font> || frei<br />
|-<br />
! 10.50.136.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.136.1 – 10.50.143.254</font> || <br />
|-<br />
! 10.50.144.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.144.1 – 10.50.159.254</font> || <br />
|-<br />
! 10.50.160.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.160.1 – 10.50.191.254</font> || <br />
|-<br />
! 10.50.192.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.192.1 – 10.50.223.254</font> || <br />
|-<br />
! 10.50.224.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.224.1 – 10.50.239.254</font> || <br />
|-<br />
! 10.50.240.0/20 ||Aufgeteilt: || <br />
|-<br />
! 10.50.240.0/21 || fffaux ||<br />
|-<br />
| || 10.50.240.1 – 10.50.240.255 || Statische Adressen<br />
|-<br />
| || 10.50.241.0 – 10.50.241.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.242.0 – 10.50.243.255 || [[Server#fff-fra1|fff-fra1]]<br />
|-<br />
| || 10.50.244.0 – 10.50.244.127 || Testinstallation Busch (Flo)<br />
|-<br />
| || <font color="grey">10.50.244.128 - 10.50.246.255</font> || <br />
|-<br />
| || 10.50.247.0 - 10.50.247.254 || | [[Server#kleeV2|kleeV2]]<br />
|-<br />
<br />
! 10.50.248.0/22 || free ||<br />
|-<br />
| || 10.50.248.1 – 10.50.248.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.249.0 - 10.50.251.254</font> || <br />
|-<br />
! 10.50.252.0/22 || TUNNEL ||<br />
|-<br />
| || 10.50.252.0 fff_ro1 || 10.50.252.1 nue1 || <br />
|-<br />
| || 10.50.252.2 fff_ro1 || 10.50.252.3 watzmann || <br />
|-<br />
| || 10.50.252.4 fff_ro1 || 10.50.252.5 staufen || <br />
|-<br />
| || 10.50.252.6 fff_ro1 || 10.50.252.7 has2 || <br />
|-<br />
| || 10.50.252.8 fff_ro1 || 10.50.252.9 has || <br />
|-<br />
| || 10.50.252.10 ro1 || 10.50.252.11 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.12 fff-has2 || 10.50.252.13 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.14 fff-gw-m1 || 10.50.252.15 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.16 KleeV2 || 10.50.252.17 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.18 KleeV2 || 10.50.252.19 nue1 ||<br />
|-<br />
| || 10.50.252.20 KleeV2 || 10.50.252.21 ro1 ||<br />
|-<br />
| || 10.50.252.22 fff-gw-yaga || 10.50.252.23 fff-wue1 ||<br />
|-<br />
| || 10.50.252.24 fff-gw-m1 || 10.50.252.25 fff-has2 ||<br />
|-<br />
| || 10.50.252.26 fff-gw-m1 || 10.50.252.27 fff-wue1 ||<br />
|-<br />
| || 10.50.252.28 fff-bbg || 10.50.252.29 fff-nue1 ||<br />
|-<br />
| || 10.50.252.30 fff-bbg || 10.50.252.31 fff-ro1 ||<br />
|-<br />
| || 10.50.252.32 fff-bbg || 10.50.252.33 fff-has2 ||<br />
|-<br />
| || 10.50.252.34 fff-bbg || 10.50.252.35 KleeV2 ||<br />
|-<br />
| || 10.50.252.36 fff-wue1 || 10.50.252.37 fff-bbg ||<br />
|-<br />
| || 10.50.252.38 fff-gw-m1 || 10.50.252.39 ro1 ||<br />
|-<br />
| || 10.50.252.40 fff-gw-yaga || 10.50.252.41 ro1 ||<br />
|-<br />
| || 10.50.252.42 fff-gw-yaga || 10.50.252.43 nue1 ||<br />
|-<br />
| || 10.50.252.44 fff-roffl || 10.50.252.45 fff-has2 ||<br />
|-<br />
| || 10.50.252.46 fff-fra1 || 10.50.252.47 fff-bbg ||<br />
|-<br />
| || 10.50.252.48 fff-fra1 || 10.50.252.49 kleeV2 ||<br />
|-<br />
| || 10.50.252.50 fff-roffl || 10.50.252.51 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.52 fff-has2 || 10.50.252.53 kleeV2 ||<br />
|-<br />
| || 10.50.252.54 fff-has2 || 10.50.252.55 fff-fra1 ||<br />
|-<br />
| || 10.50.252.56 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.57 kwadronaut ||<br />
|-<br />
| || 10.50.252.58 fff-gw-m1 || 10.50.252.59 kwadronaut ||<br />
|-<br />
| || 10.50.252.60 fff-nue1 || 10.50.252.61 kwadronaut ||<br />
|-<br />
| || 10.50.252.62 ro1 || 10.50.252.63 kwadronaut ||<br />
|-<br />
| || 10.50.252.64 staufen || 10.50.252.65 kwadronaut ||<br />
|-<br />
| || 10.50.252.66 watzmann || 10.50.252.67 kwadronaut ||<br />
|-<br />
| || 10.50.252.250 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.251 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.252 Testsystem von [[Benutzer:ChristianD]] || 10.50.252.253 Testsystem2 von [[Benutzer:ChristianD]] ||<br />
|-<br />
! 10.83.0.0/16 || free for tests ||<br />
|-<br />
| || <font color="grey">10.83.0.1 - 10.83.255.254</font> || <br />
|-<br />
|}<br />
<br />
== Statische IP-Adressen ==<br />
Dienste müssen Ihre IP-Adressen natürlich aus dem Subnetz beziehen, in welchem sie angeschlossen sind. Damit es keine Konflikte gibt, muss die IP-Adresse hier registriert werden.<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.16.0 – 10.50.17.255 || || IP-Bereich Default Hood || <br />
|-<br />
| 10.50.16.2 || fff-nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.16.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.16.11 || c.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.21 || rns3.franken.ff || DNS PoC - Recursor #3 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.16.100 || netmon.freifunk-franken.de || || [[Server#si1|Details]]<br />
|-<br />
| 10.50.16.112 ||???.franken.ff || Raspberry Pi, Test owncloud, FTP || MartinS<br />
|-<br />
| 10.50.16.128 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.150 ||Diagnose ChristianD || Diagnose ChristianD || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.16.200 ||???.franken.ff || Fileserver || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.16.212 ||???.franken.ff || NAS, verschiedene Services || JomJom<br />
|-<br />
| 10.50.16.222 ||???.franken.ff || VM, mom. nur Test || pixelchrome<br />
|-<br />
| 10.50.17.17 ||???.franken.ff || Teamspeak, sFTP, owncloud im Test || Johnny<br />
|-<br />
| 10.50.17.112 ||???.franken.ff || Webserver, Tests || wolli112<br />
|-<br />
! 10.50.32.0 – 10.50.32.255 || || IP-Bereich Fürth Hood || <br />
|-<br />
| 10.50.32.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.32.3 || fff-uk1.freifunk-franken.de || || [[Server#fff-uk1|Details]]<br />
|-<br />
| 10.50.32.4 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|- <br />
| <font color="grey">10.50.32.5</font> || <font color="grey"> (frei) </font> || || <br />
|- <br />
| <font color="grey">10.50.32.6</font> || <font color="grey"> (frei) </font> || || <br />
|- <br />
| 10.50.32.7 || kleeV2 || ||<br />
|-<br />
| 10.50.32.27 || Test-IP || Statische IP für Testzwecke || [[Benutzer:Green|Green]] <br />
|-<br />
| 10.50.32.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.32.100 || MicroNAS || anonymous FTP (10GB) || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.101 || Wetterstation || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Daten bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.110 || - || - || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.150 || ChristianD's PC || FFF-Netz ohne Internet || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.151 || feste Laptop IP || Für Speedtests mit manuellen Gateway || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.152 || RasPi || Testsystem || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
! 10.50.40.0 – 10.50.40.255 || || IP-Bereich Nürnberg Hood || <br />
|-<br />
| <strike>10.50.40.2</strike> || <strike>nue1.freifunk-franken.de</strike> || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.40.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.40.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.40.7 || fff-gw-yaga|| || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.40.8 || fff-bbg|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.10 || FFF-GW-M1 || || [[Server#FFF-GW-M1|Details]]<br />
|-<br />
| 10.50.40.11 || a.ns.franken.ff || DNS PoC - Master || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.12 || b.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.20 || - – - || Direct Connect HUB || [[Benutzer:TheFroggy|TheFroggy]]<br />
|-<br />
| 10.50.40.21 || rns1.franken.ff || DNS PoC - Recursor #1 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.22 || rns2.franken.ff || DNS PoC - Recursor #2 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.40 || fff-synology.freifunk-franken.de || || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.40.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.40.66 || flightradar.freifunk-franken.de || Dump1090 || [[Benutzer:Sixkiller6kl|sixkiller6kl]]<br />
|-<br />
| 10.50.40.98 || jabber.pm-ib.de || Jabber-Server || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.101 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.102 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.103 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.110 || ff_br_Spenglerstr || 5-GHz-Bridge Spenglerstr --> Johannis || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.111 || ff_Johannis || 5-GHz-Bridge Johannis --> Spenglerstr || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.120 || -- || 5-GHz-Access Point (Schniegling) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.121 || -- || 5-GHz-Client (Naturfreundehaus Nürnberg Mitte) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.130 || ff_nhgbr_Johnny || 5-GHz-Master (Standort Spenglerstr) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.131 || ff_nhgbr_NHG || 5-GHz-Slave (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.132 || ff_NHG_Osten || 5-GHz-Master (Standort Nachbarschaftshaus Goho, Richtung Osten) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.135 || ff_nhgswitch_NHG || POE-Switch (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.140 || ff_TS_PoE_tmp || 5-Port POE-Switch (für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.141 || ff_NS_M5_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.142 || ff_NS_M5_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.143 || ff_PB_5AC_500_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.144 || ff_PB_5AC_500_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.145 || ff_nhgbrsüd_M5loco_Master || 5-GHz-Master (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.146 || ff_Bauerngassebr_M5loco_Slave || 5-GHz-Slave (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.200 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Client, Routerfernwartung || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.201 – 10.50.40.205|| Test || bitte vorläufig freihalten, danke || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.230 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.231 ||???.franken.ff || Juniper SRX (VRF) || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.232 ||???.franken.ff || Raspberry Pi || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.233 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.234 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
| 10.50.43.165 || fffsvr01.franken.freifunk.net || SMB, FTP Server 250GB || [[Benutzer:ManuelS|ManuelS]]<br />
|-<br />
! 10.50.48.0 – 10.50.48.255 || || IP-Bereich Ansbach Hood || <br />
|-<br />
| 10.50.48.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.48.3 || fff-gw-cdfue1 || || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| 10.50.48.20 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.21 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.48.230 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.231 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.232 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.233 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.234 || || mom. nur Test || JuzeCr<br />
|-<br />
! 10.50.56.0 – 10.50.56.255 || || IP-Bereich Hassberge Hood || <br />
|-<br />
| 10.50.56.2 || <strike> nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]] </strike><br />
|-<br />
| 10.50.56.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.56.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.56.7 || fff-roffl|| || [[Server#fff-roffl|Details]]<br />
|-<br />
| 10.50.56.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| Bitte den Bereich 10.50.56.120 – 10.50.56.129 für [[Benutzer:Plocker|Plocker]] frei lassen<br />
|-<br />
| 10.50.56.123 || Teeworlds-Game-Server || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.124 || OwnCloud + Wiki || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.125 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.126 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.132 ||<strike> Webserver + MUD? || || [[Benutzer:PeterPhilipp|area52]]</strike><br />
|-<br />
! 10.50.60.0 – 10.50.60.255 || || IP-Bereich HassbergeSued Hood ||<br />
|-<br />
| 10.50.60.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.60.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.60.7 || fff-roffl|| || [[Server#fff-roffl|Details]] <br />
|-<br />
| 10.50.60.10 || Webcam Meehäusle Parkplatz|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.11 || Webcam Meehäusle Biergarten|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.100 /mediawiki || Webserver Mediawiki (in progress: Wikipedia(de)offline mirror)|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.101 /wiki || Raspi Webserver mit MediaWiki (Haßberge Wiki)|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
! 10.50.64.0 – 10.50.64.255 || || IP-Bereich Erlangen Hood || <br />
|-<br />
| 10.50.64.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.64.3 || fff-gw-yaga || || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.64.4 || fff-gw-kwadro || || [[Server#fff-gw-kwadro|Details]]<br />
|-<br />
| 10.50.64.10 || radiator.franken.ff || || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.11 || voip-1.radiator.franken.ff || VoIP mittels SIP || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.12 || cam-1.radiator.franken.ff || IP-Cam<br />
|| [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.20 || radiatrix.franken.ff || geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.21 || cam-1.radiatrix.franken.ff || IP-Cam, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.22 || voip-1.radiatrix.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.30 || long.franken.ff || geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.31 || cam-1.long.franken.ff || IP-Cam, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.33 || voip-1.long.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
! 10.50.72.0 – 10.50.79.255 || || IP-Bereich Würzburg Hood || <br />
|-<br />
| 10.50.72.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.72.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.72.6 || fff-wue1|| || [[Server#fff-wue1|Details]] <br />
|-<br />
| 10.50.72.7 || kleeV2|| || [[Server#kleeV2|Details]] <br />
|-<br />
| 10.50.72.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.72.100 || staddi99.franken.ff || geplant || [[Benutzer:Staddi99|Staddi99]]<br />
|-<br />
| 10.50.72.101 || || geplant || [[Benutzer:Staddi99|Staddi99]]<br />
|-<br />
| 10.50.72.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
! 10.50.80.0 – 10.50.87.255 || || IP-Bereich BGL Hood || <br />
|-<br />
| 10.50.80.1 || watzmann || ||<br />
|-<br />
| 10.50.80.2 || staufen || ||<br />
|-<br />
! 10.50.88.0 – 10.50.95.255 || || IP-Bereich NbgLand Hood || <br />
|-<br />
| 10.50.88.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.88.10 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.170 ||???.franken.ff || 5-GHz Richtfunk AP || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.171 ||???.franken.ff || 5-GHz Richtfunk Client || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.172 ||???.franken.ff || VM zum Testen || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
!10.50.240.1 – 10.50.247.254 || || IP-Bereich aux Hood || <br />
|-<br />
| 10.50.240.1 || fff-bbg || ||<br />
|-<br />
| 10.50.240.2 || fff-fra1 || ||<br />
|-<br />
| 10.50.240.7 || kleeV2 || ||<br />
|-<br />
| 10.50.240.20 || || Testgateway Flo für Hotel Busch |||<br />
|}</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Portal:Netz&diff=5253
Portal:Netz
2016-01-02T16:33:13Z
<p>Green: /* Liste der Subnetze */</p>
<hr />
<div>== Das Netz ==<br />
Eine Karte der aktiven Router gibt es [https://netmon.freifunk-franken.de/map.php hier].<br />
<br />
Eine Karte der Hoods ist [http://keyserver.freifunk-franken.de/fff/voronoimap.php hier] zu finden.<br />
<br />
Die [https://netmon.freifunk-franken.de/routerlist.php Liste der Router] kann dank Netmon immer live verfolgt werden. Infos über die Schreibweise (z.B. "/20") gibt es in der [http://de.wikipedia.org/wiki/CIDR Wikipedia].<br />
<br />
=== Gateway ===<br />
Erste Versuche einer sinnvollen Aufteilung von Gateways. Erweiterungen und Verbesserungen sind jederzeit erwünscht. [https://pad.freifunk.net/p/Gatewayaufteilung-Franken Zum Pad]<br />
<br />
== IP-Netz ==<br />
Mit der Netz-Umstellung vom 22.03.2014 haben wir nicht mehr länger ein großes [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_2_.E2.80.93_Sicherungsschicht_.28Data_Link_Layer.29 Layer-II-Netz], welches durch das [https://de.wikipedia.org/wiki/B.A.T.M.A.N. B.A.T.M.A.N. advanced]-Protokoll geroutet wird. Seitdem gibt es mehrere [https://de.wikipedia.org/wiki/OSI-Modell#Schicht_3_.E2.80.93_Vermittlungsschicht_.28Network_Layer.29 Layer-III-Netze] (Hoods). Ein Layer-III-Netz entsteht grundsätzlich, indem hier ein Subnetz eingetragen wird. Wie dabei genau vorgegangen wird, steht in [[HoodVerwaltung]].<br />
Für jedes Subnetz muss separat abgewogen werden, wie groß es werden wird und wo es dann in die bestehenden Subnetze am besten eingegliedert werden kann.<br />
<br />
==== DHCP ====<br />
[[Datei:Hoods.png|200px|thumb|right|Vorschlag für die Hood-Organisation]]<br />
Damit simple Clients das neue Subnetz nutzen können, muss ein eigener DHCP-Server pro Subnetz bereit gestellt werden. Es macht dabei häufig Sinn, das Subnetz in IP-Bereiche aufzuteilen, die von mehreren DHCP-Servern verteilt werden. Ein zweiter DHCP-Server ermöglicht zum einen eine Lastverteilung, zum anderen erhöht sich die Ausfallsicherheit. Der DHCP-Server muss den Clients ein Default-Gateway und mindestens einen DNS-Server zuweisen. Da das Default-Gateway ebenfalls innerhalb des Subnetzes liegen muss, bietet es sich an, den selben Server, auf dem das DHCP läuft, zu nutzen.<br />
<br />
==== OLSR-Router ====<br />
Das Subnetz muss anschließend an das vorhandene Freifunknetz angeschlossen werden. Dazu muss eine Verbindung zu einem bestehenden OLSR-Router aufgebaut werden. Dies kann eine VPN-Verbindung, aber auch eine Wifi-Verbindung sein und muss individuell zwischen den zwei Parteien ausgehandelt werden. Es kann sinnvoll sein, Verbindungen zu mehr als einem OLSR-Router zu haben. Sobald der eigene Router an das OLSR-Netz angebunden ist, ist er selbst ein OLSR-Router.<br />
<br />
An den eigenen OLSR-Router können nun Accesspoints angeschlossen werden. Dies kann per VPN, WLAN, Kabel oder anderweitig geschehen. Es ist auch möglich, den Accesspoint selbst als OLSR-Router anzubinden. Auch diese Konfiguration ist individuell zu klären. Ein Accesspoint kann ein (oder mehrere) einfacher Wifi-AP oder auch ein Array von mehreren B.A.T.M.A.N.-Knoten sein. Es sollte vermieden werden, dass sich Subnetze vermischen. Dies würde immer dann passieren, wenn zwei Layer-II-Netze, die eigentlich unterschiedliche Subnetze verteilen, verbunden werden. Besonders beim B.A.T.M.A.N.-Protokoll besteht hier leicht diese Gefahr; daher sollte für jedes Subnetz eine eigene BSSID und ESSID gewählt werden.<br />
<br />
==== Aus Routersicht ====<br />
Nur Router in einer Hood können sich per B.A.T.M.A.N. advanced vermaschen, sowohl per VPN, also auch per WLAN. Daher müssen Router die räumlich nahe beieinander stehen auch in derselben Hood sein. Durch das Vermaschen des Netzes wird allerdings auch Verwaltungs-Verkehr erzeugt (Overhead). Je größer die Hood, desto größer der Overhead.<br />
<br />
Eine Verbindung zwischen Routern in unterschiedlichen Hoods ist per IP (OSI Schicht 3) möglich.<br />
<br />
Wenn im Netmon kein Standort eingegeben wurde, dann landet der Router in der Dafault-Hood.<br />
<br />
==== Monitoring (Netmon) ====<br />
Aktuell können sich Knoten nur über ein IPv6-Link-Local-Interface beim Netmon anmelden und Netmon kann die Knoten nur über eine IPv6-Link-Local-Adresse abfragen. Hier muss ein neuer Mechanismus gefunden werden, der es ermöglicht, die Knoten über Subnetze hinweg anzusprechen.<br />
<br />
Als Workaround ist es möglich, über einen Layer-II-Tunnel zum Netmon-Server das Subnetz an das Netmon anzubinden. Auf dem Netmon-Server werden alle Subnetze in einem Bridge-Interface zusammengefasst, welches keine Pakete weiterleiten kann.<br />
<br />
==== Wireless-LAN ====<br />
Wir haben uns auf folgende WLAN-Parameter verständigt:<br />
'''ESSID: franken.freifunk.net'''. Kanal 1.<br />
<br />
== Liste der Subnetze ==<br />
{|<br />
! !! Bereich !! Bereitgestellt durch<br />
|-<br />
! 10.50.0.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.0.1 – 10.50.15.254</font> || <br />
|-<br />
! 10.50.16.0/20 || Default Hood ||<br />
|-<br />
| || 10.50.16.1 – 10.50.17.255 || Statische Adressen<br />
|-<br />
| || 10.50.18.0 – 10.50.19.255 || --<br />
|-<br />
| || 10.50.20.0 – 10.50.21.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || <font color="grey">10.50.22.0 – 10.50.23.254 </font> || <br />
|-<br />
| || <font color="grey">10.50.24.0 – 10.50.31.254 </font> || <br />
|-<br />
! 10.50.32.0/21 || Fürth Hood ||<br />
|-<br />
| || 10.50.32.1 – 10.50.32.255 || Statische Adressen<br />
|-<br />
| || 10.50.33.0 – 10.50.34.255 || --<br />
|-<br />
| || 10.50.35.0 – 10.50.36.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.37.0 – 10.50.37.255 || [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || 10.50.38.0 – 10.50.39.254 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.40.0/21 || Nürnberg Hood ||<br />
|-<br />
| || 10.50.40.1 – 10.50.40.255 || Statische Adressen<br />
|-<br />
| || 10.50.41.0 – 10.50.42.255 || [[Server#FFF-GW-M1|FFF-GW-M1]]<br />
|-<br />
| || <font color="grey"> 10.50.43.0 - 10.50.43.255 </font> || <br />
|-<br />
| || 10.50.44.0 – 10.50.44.255 || (umgezogen) [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| ||10.50.45.0 – 10.50.46.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.47.0 – 10.50.47.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.48.0/21 || Ansbach Hood ||<br />
|-<br />
| || 10.50.48.1 – 10.50.48.255 || Statische Adressen<br />
|-<br />
| || 10.50.49.0 – 10.50.50.255 || <br />
|-<br />
| || 10.50.51.0 – 10.50.52.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.53.0 – 10.50.54.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| || <font color="grey">10.50.55.0 – 10.50.55.254</font> || <br />
|-<br />
! 10.50.56.0/22 || Hassberge Hood ||<br />
|-<br />
| || 10.50.56.1 – 10.50.56.255 || Statische Adressen<br />
|-<br />
| || 10.50.57.0 – 10.50.57.255 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
| || 10.50.58.0 – 10.50.58.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.59.0 – 10.50.59.254 || [[Server#fff-has|fff-has]]<br />
|-<br />
! 10.50.60.0/22 || HassbergeSued Hood ||<br />
|-<br />
| || 10.50.60.1 – 10.50.60.255 || Statische Adressen<br />
|-<br />
| || 10.50.61.0 – 10.50.61.255 || [[Server#fff-has|fff-has]]<br />
|-<br />
| || 10.50.62.0 – 10.50.62.255 || [[Server#fff-has2|fff-has2]]<br />
|-<br />
| || 10.50.63.0 – 10.50.63.254 || [[Server#fff-roffl|fff-roffl]]<br />
|-<br />
! 10.50.64.0/21 || Erlangen Hood ||<br />
|-<br />
| || 10.50.64.1 – 10.50.64.255 || Statische Adressen<br />
|-<br />
| || 10.50.65.0 – 10.50.66.255 || [[Server#fff-gw-kwadro|fff-gw-kwadro]]<br />
|-<br />
| || 10.50.67.0 – 10.50.68.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.69.0 – 10.50.71.254 || [[Server#fff-gw-yaga|fff-gw-yaga]]<br />
|-<br />
! 10.50.72.0/21 || Würzburg Hood ||<br />
|-<br />
| || 10.50.72.1 – 10.50.72.255 || Statische Adressen<br />
|-<br />
| || <font color="grey"> 10.50.73.0 – 10.50.74.255 </font>|| <br />
|-<br />
| || 10.50.75.0 – 10.50.76.255 || [[Server#fff-nue1|fff-nue1.wavecloud.de]]<br />
|-<br />
| || 10.50.77.0 – 10.50.77.255 || [[Server#kleeV2|kleeV2]]<br />
|-<br />
| || <font color="grey"> 10.50.78.0 – 10.50.78.255 </font>|| <br />
|-<br />
| || 10.50.79.0 – 10.50.79.254 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
! 10.50.80.0/21 || BGL ||<br />
|-<br />
| || 10.50.80.1 – 10.50.80.255 || Statische Adressen<br />
|-<br />
| || 10.50.81.0 – 10.50.82.255 || [[Server#watzmann|watzmann]]<br />
|-<br />
| || 10.50.83.0 – 10.50.84.255 || [[Server#staufen|staufen]]<br />
|-<br />
! 10.50.88.0/21 || NbgLand Hood ||<br />
|-<br />
| || 10.50.88.1 – 10.50.88.255 || Statische Adressen<br />
|-<br />
| || 10.50.89.0 – 10.50.89.255 || [[Server#fff-wue1|fff-wue1]]<br />
|-<br />
| || <font color="grey">10.50.90.0 - 10.50.93.255</font> || <br />
|-<br />
| || 10.50.94.0 – 10.50.95.255 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]]<br />
|-<br />
! 10.50.96.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.96.1 – 10.50.127.254</font> || <br />
|-<br />
! 10.50.128.0/24 || Test von Casandro ||<br />
|-<br />
| || 10.50.128.20 – 10.50.128.200 || 10.50.128.1<br />
|-<br />
! 10.50.129.0/24 || free ||<br />
|-<br />
| || || <br />
|-<br />
! 10.50.130.0/24 || free ||<br />
|-<br />
| || <font color="black">10.50.130.1 – 10.50.130.254</font> || Testbereich ChristianD für [https://wiki.freifunk-franken.de/w/Standorte/Fuerth/Unterfuerberg/L3Konzept Konzept Unterfürberg]<br />
|-<br />
! 10.50.131.0/24 || free ||<br />
|-<br />
| || <font color="grey">10.50.131.1 – 10.50.131.254</font> || <br />
|-<br />
! 10.50.132.0/22 || border:none gateway ||<br />
|-<br />
| || 10.50.132.1 – 10.50.132.255 || Statische Adressen<br />
|-<br />
| || 10.50.133.0 – 10.50.134.255 || DHCP<br />
|-<br />
| || <font color="grey">10.50.135.0 – 10.50.135.254</font> || frei<br />
|-<br />
! 10.50.136.0/21 || free ||<br />
|-<br />
| || <font color="grey">10.50.136.1 – 10.50.143.254</font> || <br />
|-<br />
! 10.50.144.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.144.1 – 10.50.159.254</font> || <br />
|-<br />
! 10.50.160.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.160.1 – 10.50.191.254</font> || <br />
|-<br />
! 10.50.192.0/19 || free ||<br />
|-<br />
| || <font color="grey">10.50.192.1 – 10.50.223.254</font> || <br />
|-<br />
! 10.50.224.0/20 || free ||<br />
|-<br />
| || <font color="grey">10.50.224.1 – 10.50.239.254</font> || <br />
|-<br />
! 10.50.240.0/20 ||Aufgeteilt: || <br />
|-<br />
! 10.50.240.0/21 || fffaux ||<br />
|-<br />
| || 10.50.240.1 – 10.50.240.255 || Statische Adressen<br />
|-<br />
| || 10.50.241.0 – 10.50.241.255 || [[Server#fff-bbg|fff-bbg]]<br />
|-<br />
| || 10.50.242.0 – 10.50.243.255 || [[Server#fff-fra1|fff-fra1]]<br />
|-<br />
| || 10.50.244.0 – 10.50.244.127 || Testinstallation Busch (Flo)<br />
|-<br />
| || <font color="grey">10.50.244.128 - 10.50.246.255</font> || <br />
|-<br />
| || 10.50.247.0 - 10.50.247.254 || | [[Server#kleeV2|kleeV2]]<br />
|-<br />
<br />
! 10.50.248.0/22 || free ||<br />
|-<br />
| || 10.50.248.1 – 10.50.248.255 || Statische Adressen<br />
|-<br />
| || <font color="grey">10.50.249.0 - 10.50.251.254</font> || <br />
|-<br />
! 10.50.252.0/22 || TUNNEL ||<br />
|-<br />
| || 10.50.252.0 fff_ro1 || 10.50.252.1 nue1 || <br />
|-<br />
| || 10.50.252.2 fff_ro1 || 10.50.252.3 watzmann || <br />
|-<br />
| || 10.50.252.4 fff_ro1 || 10.50.252.5 staufen || <br />
|-<br />
| || 10.50.252.6 fff_ro1 || 10.50.252.7 has2 || <br />
|-<br />
| || 10.50.252.8 fff_ro1 || 10.50.252.9 has || <br />
|-<br />
| || 10.50.252.10 ro1 || 10.50.252.11 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.12 fff-has2 || 10.50.252.13 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.14 fff-gw-m1 || 10.50.252.15 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.16 KleeV2 || 10.50.252.17 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || <br />
|-<br />
| || 10.50.252.18 KleeV2 || 10.50.252.19 nue1 ||<br />
|-<br />
| || 10.50.252.20 KleeV2 || 10.50.252.21 ro1 ||<br />
|-<br />
| || 10.50.252.22 fff-gw-yaga || 10.50.252.23 fff-wue1 ||<br />
|-<br />
| || 10.50.252.24 fff-gw-m1 || 10.50.252.25 fff-has2 ||<br />
|-<br />
| || 10.50.252.26 fff-gw-m1 || 10.50.252.27 fff-wue1 ||<br />
|-<br />
| || 10.50.252.28 fff-bbg || 10.50.252.29 fff-nue1 ||<br />
|-<br />
| || 10.50.252.30 fff-bbg || 10.50.252.31 fff-ro1 ||<br />
|-<br />
| || 10.50.252.32 fff-bbg || 10.50.252.33 fff-has2 ||<br />
|-<br />
| || 10.50.252.34 fff-bbg || 10.50.252.35 KleeV2 ||<br />
|-<br />
| || 10.50.252.36 fff-wue1 || 10.50.252.37 fff-bbg ||<br />
|-<br />
| || 10.50.252.38 fff-gw-m1 || 10.50.252.39 ro1 ||<br />
|-<br />
| || 10.50.252.40 fff-gw-yaga || 10.50.252.41 ro1 ||<br />
|-<br />
| || 10.50.252.42 fff-gw-yaga || 10.50.252.43 nue1 ||<br />
|-<br />
| || 10.50.252.44 fff-roffl || 10.50.252.45 fff-has2 ||<br />
|-<br />
| || 10.50.252.46 fff-fra1 || 10.50.252.47 fff-bbg ||<br />
|-<br />
| || 10.50.252.48 fff-fra1 || 10.50.252.49 kleeV2 ||<br />
|-<br />
| || 10.50.252.50 fff-roffl || 10.50.252.51 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.52 fff-has2 || 10.50.252.53 kleeV2 ||<br />
|-<br />
| || 10.50.252.54 fff-has2 || 10.50.252.55 fff-fra1 ||<br />
|-<br />
| || 10.50.252.56 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.57 kwadronaut ||<br />
|-<br />
| || 10.50.252.58 fff-gw-m1 || 10.50.252.59 kwadronaut ||<br />
|-<br />
| || 10.50.252.60 fff-nue1 || 10.50.252.61 kwadronaut ||<br />
|-<br />
| || 10.50.252.62 ro1 || 10.50.252.63 kwadronaut ||<br />
|-<br />
| || 10.50.252.64 staufen || 10.50.252.65 kwadronaut ||<br />
|-<br />
| || 10.50.252.66 watzmann || 10.50.252.67 kwadronaut ||<br />
|-<br />
| || 10.50.252.250 [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || 10.50.252.251 Testsystem von [[Benutzer:ChristianD]] ||<br />
|-<br />
| || 10.50.252.252 Testsystem von [[Benutzer:ChristianD]] || 10.50.252.253 Testsystem2 von [[Benutzer:ChristianD]] ||<br />
|-<br />
! 10.83.0.0/16 || free for tests ||<br />
|-<br />
| || <font color="grey">10.83.0.1 - 10.83.255.254</font> || <br />
|-<br />
|}<br />
<br />
== Statische IP-Adressen ==<br />
Dienste müssen Ihre IP-Adressen natürlich aus dem Subnetz beziehen, in welchem sie angeschlossen sind. Damit es keine Konflikte gibt, muss die IP-Adresse hier registriert werden.<br />
<br />
{|<br />
! Statische IP !! Hostname !! Beschreibung !! Admins<br />
|-<br />
! 10.50.16.0 – 10.50.17.255 || || IP-Bereich Default Hood || <br />
|-<br />
| 10.50.16.2 || fff-nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.16.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.16.11 || c.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.21 || rns3.franken.ff || DNS PoC - Recursor #3 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.16.100 || netmon.freifunk-franken.de || || [[Server#si1|Details]]<br />
|-<br />
| 10.50.16.112 ||???.franken.ff || Raspberry Pi, Test owncloud, FTP || MartinS<br />
|-<br />
| 10.50.16.128 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.16.150 ||Diagnose ChristianD || Diagnose ChristianD || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.16.200 ||???.franken.ff || Fileserver || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.16.212 ||???.franken.ff || NAS, verschiedene Services || JomJom<br />
|-<br />
| 10.50.16.222 ||???.franken.ff || VM, mom. nur Test || pixelchrome<br />
|-<br />
| 10.50.17.17 ||???.franken.ff || Teamspeak, sFTP, owncloud im Test || Johnny<br />
|-<br />
| 10.50.17.112 ||???.franken.ff || Webserver, Tests || wolli112<br />
|-<br />
! 10.50.32.0 – 10.50.32.255 || || IP-Bereich Fürth Hood || <br />
|-<br />
| 10.50.32.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.32.3 || fff-uk1.freifunk-franken.de || || [[Server#fff-uk1|Details]]<br />
|-<br />
| 10.50.32.4 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|- <br />
| <font color="grey">10.50.32.5</font> || <font color="grey"> (frei) </font> || || <br />
|- <br />
| <font color="grey">10.50.32.6</font> || <font color="grey"> (frei) </font> || || <br />
|- <br />
| 10.50.32.7 || kleeV2 || ||<br />
|-<br />
| 10.50.32.27 || Test-IP || Statische IP für Testzwecke || [[Benutzer:Green|Green]] <br />
|-<br />
| 10.50.32.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.32.100 || MicroNAS || anonymous FTP (10GB) || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.101 || Wetterstation || [http://www.wunderground.com/personal-weather-station/dashboard?ID=IBAYERNF23 Wetter-Daten bei WUnderground] || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.110 || - || - || [[Benutzer:delphiN|delphiN]]<br />
|-<br />
| 10.50.32.150 || ChristianD's PC || FFF-Netz ohne Internet || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.151 || feste Laptop IP || Für Speedtests mit manuellen Gateway || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
| 10.50.32.152 || RasPi || Testsystem || [[Benutzer:ChristianD|ChristianD]] <br />
|-<br />
! 10.50.40.0 – 10.50.40.255 || || IP-Bereich Nürnberg Hood || <br />
|-<br />
| <strike>10.50.40.2</strike> || <strike>nue1.freifunk-franken.de</strike> || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.40.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.40.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.40.7 || fff-gw-yaga|| || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.40.8 || fff-bbg|| || [[Server#fff-bbg|Details]]<br />
|-<br />
| 10.50.40.10 || FFF-GW-M1 || || [[Server#FFF-GW-M1|Details]]<br />
|-<br />
| 10.50.40.11 || a.ns.franken.ff || DNS PoC - Master || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.12 || b.ns.franken.ff || DNS PoC - Slave || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.20 || - – - || Direct Connect HUB || [[Benutzer:TheFroggy|TheFroggy]]<br />
|-<br />
| 10.50.40.21 || rns1.franken.ff || DNS PoC - Recursor #1 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.22 || rns2.franken.ff || DNS PoC - Recursor #2 || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.40 || fff-synology.freifunk-franken.de || || [[Benutzer:mgadmin|Scheese]]<br />
|-<br />
| 10.50.40.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.40.66 || flightradar.freifunk-franken.de || Dump1090 || [[Benutzer:Sixkiller6kl|sixkiller6kl]]<br />
|-<br />
| 10.50.40.98 || jabber.pm-ib.de || Jabber-Server || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.101 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.102 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.103 || K4CG || Dinge || [[Benutzer:Gpunktschmitz|Gpunktschmitz]]<br />
|-<br />
| 10.50.40.110 || ff_br_Spenglerstr || 5-GHz-Bridge Spenglerstr --> Johannis || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.111 || ff_Johannis || 5-GHz-Bridge Johannis --> Spenglerstr || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.120 || -- || 5-GHz-Access Point (Schniegling) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.121 || -- || 5-GHz-Client (Naturfreundehaus Nürnberg Mitte) || [[Benutzer:Schniegling_open|Schniegling_open]]<br />
|-<br />
| 10.50.40.130 || ff_nhgbr_Johnny || 5-GHz-Master (Standort Spenglerstr) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.131 || ff_nhgbr_NHG || 5-GHz-Slave (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.132 || ff_NHG_Osten || 5-GHz-Master (Standort Nachbarschaftshaus Goho, Richtung Osten) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.135 || ff_nhgswitch_NHG || POE-Switch (Standort Nachbarschaftshaus Goho) || [[Benutzer:NaGoHo|NaGoHo]]<br />
|-<br />
| 10.50.40.140 || ff_TS_PoE_tmp || 5-Port POE-Switch (für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.141 || ff_NS_M5_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.142 || ff_NS_M5_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.143 || ff_PB_5AC_500_Master_tmp || 5-GHz-Master (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.144 || ff_PB_5AC_500_Slave_tmp || 5-GHz-Slave (Richtfunkstrecke für temp. Installationen) || [[Benutzer:Michaelstingl|Michaelstingl]]<br />
|-<br />
| 10.50.40.145 || ff_nhgbrsüd_M5loco_Master || 5-GHz-Master (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.146 || ff_Bauerngassebr_M5loco_Slave || 5-GHz-Slave (Richtfunkstrecke zw. NHG und Bauerngasse) || [[Benutzer:Johnny|Johnny]]<br />
|-<br />
| 10.50.40.200 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Client, Routerfernwartung || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.201 – 10.50.40.205|| Test || bitte vorläufig freihalten, danke || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.40.230 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.231 ||???.franken.ff || Juniper SRX (VRF) || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.232 ||???.franken.ff || Raspberry Pi || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.233 ||???.franken.ff || DNS PoC || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.234 ||???.franken.ff || $Zeuch VM || [[Benutzer:Shl|SHL]]<br />
|-<br />
| 10.50.40.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
| 10.50.43.165 || fffsvr01.franken.freifunk.net || SMB, FTP Server 250GB || [[Benutzer:ManuelS|ManuelS]]<br />
|-<br />
! 10.50.48.0 – 10.50.48.255 || || IP-Bereich Ansbach Hood || <br />
|-<br />
| 10.50.48.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.48.3 || fff-gw-cdfue1 || || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdan1]]<br />
|-<br />
| 10.50.48.20 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.21 ||???.franken.ff || RF-JomJom-1 || JomJom<br />
|-<br />
| 10.50.48.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.48.230 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.231 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.232 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.233 || || mom. nur Test || JuzeCr<br />
|-<br />
| 10.50.48.234 || || mom. nur Test || JuzeCr<br />
|-<br />
! 10.50.56.0 – 10.50.56.255 || || IP-Bereich Hassberge Hood || <br />
|-<br />
| 10.50.56.2 || <strike> nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]] </strike><br />
|-<br />
| 10.50.56.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.56.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.56.7 || fff-roffl|| || [[Server#fff-roffl|Details]]<br />
|-<br />
| 10.50.56.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| Bitte den Bereich 10.50.56.120 – 10.50.56.129 für [[Benutzer:Plocker|Plocker]] frei lassen<br />
|-<br />
| 10.50.56.123 || Teeworlds-Game-Server || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.124 || OwnCloud + Wiki || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.125 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.126 || Test || || [[Benutzer:Plocker|Plocker]]<br />
|-<br />
| 10.50.56.132 ||<strike> Webserver + MUD? || || [[Benutzer:PeterPhilipp|area52]]</strike><br />
|-<br />
! 10.50.60.0 – 10.50.60.255 || || IP-Bereich HassbergeSued Hood ||<br />
|-<br />
| 10.50.60.3 || fff-has|| || [[Server#fff-has|Details]] <br />
|-<br />
| 10.50.60.4 || fff-has2|| || [[Server#fff-has2|Details]] <br />
|-<br />
| 10.50.60.7 || fff-roffl|| || [[Server#fff-roffl|Details]] <br />
|-<br />
| 10.50.60.10 || Webcam Meehäusle Parkplatz|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.11 || Webcam Meehäusle Biergarten|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.100 /mediawiki || Webserver Mediawiki (in progress: Wikipedia(de)offline mirror)|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
| 10.50.60.101 /wiki || Raspi Webserver mit MediaWiki (Haßberge Wiki)|| || [[Benutzer:moexe|moexe]]<br />
|-<br />
! 10.50.64.0 – 10.50.64.255 || || IP-Bereich Erlangen Hood || <br />
|-<br />
| 10.50.64.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
| 10.50.64.3 || fff-gw-yaga || || [[Server#fff-gw-yaga|Details]]<br />
|-<br />
| 10.50.64.4 || fff-gw-kwadro || || [[Server#fff-gw-kwadro|Details]]<br />
|-<br />
| 10.50.64.10 || radiator.franken.ff || || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.11 || voip-1.radiator.franken.ff || VoIP mittels SIP || [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.12 || cam-1.radiator.franken.ff || IP-Cam<br />
|| [[Benutzer:Radiator|Radiator]]<br />
|-<br />
| 10.50.64.20 || radiatrix.franken.ff || geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.21 || cam-1.radiatrix.franken.ff || IP-Cam, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.22 || voip-1.radiatrix.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Radiatrix|Radiatrix]]<br />
|-<br />
| 10.50.64.30 || long.franken.ff || geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.31 || cam-1.long.franken.ff || IP-Cam, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.33 || voip-1.long.franken.ff || VoIP mittels SIP, geplant || [[Benutzer:Long|Long]]<br />
|-<br />
| 10.50.64.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
! 10.50.72.0 – 10.50.79.255 || || IP-Bereich Würzburg Hood || <br />
|-<br />
| 10.50.72.2 || nue1.freifunk-franken.de || || [[Server#fff-nue1|Details]]<br />
|-<br />
|<strike>10.50.72.3</strike> ||<strike>fff-has</strike>|| || [[Server#fff-has|Details]]<br />
|-<br />
| 10.50.72.6 || fff-wue1|| || [[Server#fff-wue1|Details]] <br />
|-<br />
| 10.50.72.7 || kleeV2|| || [[Server#kleeV2|Details]] <br />
|-<br />
| 10.50.72.50 || fff-monitoring-client1.freifunk-franken.de || || [[Benutzer:Magenbrot|magenbrot]]<br />
|-<br />
| 10.50.72.100 || staddi99.franken.ff || geplant || [[Benutzer:Staddi99|Staddi99]]<br />
|-<br />
| 10.50.72.101 || || geplant || [[Benutzer:Staddi99|Staddi99]]<br />
|-<br />
| 10.50.72.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
! 10.50.80.0 – 10.50.87.255 || || IP-Bereich BGL Hood || <br />
|-<br />
| 10.50.80.1 || watzmann || ||<br />
|-<br />
| 10.50.80.2 || staufen || ||<br />
|-<br />
! 10.50.88.0 – 10.50.95.255 || || IP-Bereich NbgLand Hood || <br />
|-<br />
| 10.50.88.6 || fff-wue1|| || [[Server#fff-wue1|Details]]<br />
|-<br />
| 10.50.88.10 || [[Server#Gateway_Server_.22fff-gw-cd.2A.2A.2A1.22|fff-gw-cdfue1]] || Gateway || [[Benutzer:ChristianD|ChristianD]]<br />
|-<br />
| 10.50.88.170 ||???.franken.ff || 5-GHz Richtfunk AP || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.171 ||???.franken.ff || 5-GHz Richtfunk Client || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.172 ||???.franken.ff || VM zum Testen || [[Benutzer:Andre|Andre]]<br />
|-<br />
| 10.50.88.255 || Mifritscher-Test1 || testClient1 || [[Benutzer:mifritscher|mifritscher]]<br />
|-<br />
!10.50.240.1 – 10.50.247.254 || || IP-Bereich aux Hood || <br />
|-<br />
| 10.50.240.1 || fff-bbg || ||<br />
|-<br />
| 10.50.240.2 || fff-fra1 || ||<br />
|-<br />
| 10.50.240.20 || || Testgateway Flo für Hotel Busch |||<br />
|}</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Liste_bekannter_Aux-FW_Router&diff=5174
Liste bekannter Aux-FW Router
2015-12-23T03:10:44Z
<p>Green: </p>
<hr />
<div>Um den Überblick über die mit Aux-FW geflashten Router zu behalten, wird eine Übersichtstabelle über die bekannten (d.h. zurückgemeldeten) Router geführt.<br />
<br />
{|<br />
! Routername !! Router-MAC !! gemeldet von !! gemeldet am !! Bemerkungen<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1317 Notunterkunft Turnhalle] || 14CC204D4786 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1318 Notunterkunft Turnhalle1] || 30B5C2AC26D8 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1355 ArnsteinerNetz0001] || 30:b5:c2:bd:77:ba || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1716 ArnsteinerNetz0002] || 30.b5:c2:bd:78:86 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1484 ArnsteinerNetz0005] || 30:b5:c2:88:47:14 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1754 ArnsteinerNetz0006] || 30:b5:c2:88:4e:00 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1248 ArnsteinerNetz002] || 30:b5:c2:d9:c8:ae || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1247 ArnsteinerNetz003] || 30:b5:c2:d9:c8:18 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1753 ArnsteinerNetz004] || 30:b5:c2:d9:c6:de || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || reiner AP, kein Mesh, Clientzählung durch Meshrouter "ArnsteinerNetz002" 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=583 WS13W01WR1043] || e8:de:27:fd:2b:aa || [https://netmon.freifunk-franken.de/user.php?user_id=6 delphiN] || 03.11.2015 || Beta 2 Testbetrieb<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1768 HabuRef01] || 30B5C20E8AE0 || [https://netmon.freifunk-franken.de/user.php?user_id=438 DerMichy] || 15.11.2015 || Pending installation in Hammelburg, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1766 Tannenberg01] || 60:E3:27:2A:56:46 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || Pending installation in Rehau, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1769 Tannenberg02] || 30:B5:C2:E2:FD:EE || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || Pending installation in Rehau, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1770 Tannenberg03] || 60:E3:27:2A:58:E4 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || Pending installation in Rehau, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1751 AHKRockenbrunner1] || A0:F3:C1:76:4F:20 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=860 AHKRockenbrunner2] || C0:4A:00:0B:A8:94 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=856 AHKRockenbrunner3] || C4:6E:1F:F5:F4:AC || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1861 AHKRockenbrunner4] || 30:B5:C2:81:08:DA || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1650 OBT1] || 14cc2030e9ce || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1651 OBT2] || 14CC2030EA0C || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1659 OBT3] || 30B5C2D9B4AE || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1781 OBT4] || 30B5C2D9BD72 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1782 OBT5] || 30B5C2D9B522 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1842 ap1.refugees.kleinheubach] || 30:B5:C2:B0:56:0E || [https://netmon.freifunk-franken.de/user.php?user_id=446 oswald] || 30.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1847 stein-knauppstr-01] || C46E1F3B4262 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1845 stein-knauppstr-02] || E894F66D16A2 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1844 stein-knauppstr-03] || E894F6B981F6 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1848 stein-knauppstr-04] || 10FEEDCD9B3C || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1904 AsylcenterEbelsbach] || 30B5C2E301A6 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1319 AsylcenterEbelsbach1] || 30B5C2CB356C || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1591 refugees21.wue] || 68:72:51:2c:2f:9c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1602 refugees22.wue] || 12:bc:f9:69:d3:5c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1610 refugees23.wue] || 68:72:51:2c:30:bb || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2005 wue.N2N-ev.refugees.aux.001] || 60:e3:27:bd:ce:08 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2004 wue.N2N-ev.refugees.aux.002] || 60:e3:27:c7:30:3c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1819 wue.N2N-ev.refugees.aux.003] || 60:e3:27:c7:2f:d6 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2014 wue.N2N-ev.refugees.aux.004] || 14:cc:20:87:3c:5e || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2010 wue.N2N-ev.refugees.aux.005] || 60:e3:27:82:00:72 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2011 wue.N2N-ev.refugees.aux.006] || 60:e3:27:82:0a:3a || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2012 wue.N2N-ev.refugees.aux.007] || 68:72:51:2c:2c:28 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 22.12.2015 ||<br />
|}<br />
<br />
Mehr Infos über die Aux-Firmware [https://wiki.freifunk-franken.de/w/Was_ist_die_aux_Firmware hier.]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Liste_bekannter_Aux-FW_Router&diff=5166
Liste bekannter Aux-FW Router
2015-12-22T08:14:02Z
<p>Green: </p>
<hr />
<div>Um den Überblick über die mit Aux-FW geflashten Router zu behalten, wird eine Übersichtstabelle über die bekannten (d.h. zurückgemeldeten) Router geführt.<br />
<br />
{|<br />
! Routername !! Router-MAC !! gemeldet von !! gemeldet am !! Bemerkungen<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1317 Notunterkunft Turnhalle] || 14CC204D4786 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1318 Notunterkunft Turnhalle1] || 30B5C2AC26D8 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1355 ArnsteinerNetz0001] || 30:b5:c2:bd:77:ba || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1716 ArnsteinerNetz0002] || 30.b5:c2:bd:78:86 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1484 ArnsteinerNetz0005] || 30:b5:c2:88:47:14 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1754 ArnsteinerNetz0006] || 30:b5:c2:88:4e:00 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1248 ArnsteinerNetz002] || 30:b5:c2:d9:c8:ae || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1247 ArnsteinerNetz003] || 30:b5:c2:d9:c8:18 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1753 ArnsteinerNetz004] || 30:b5:c2:d9:c6:de || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || reiner AP, kein Mesh, Clientzählung durch Meshrouter "ArnsteinerNetz002" 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=583 WS13W01WR1043] || e8:de:27:fd:2b:aa || [https://netmon.freifunk-franken.de/user.php?user_id=6 delphiN] || 03.11.2015 || Beta 2 Testbetrieb<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1768 HabuRef01] || 30B5C20E8AE0 || [https://netmon.freifunk-franken.de/user.php?user_id=438 DerMichy] || 15.11.2015 || Pending installation in Hammelburg, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1766 Tannenberg01] || 60:E3:27:2A:56:46 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || Pending installation in Rehau, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1769 Tannenberg02] || 30:B5:C2:E2:FD:EE || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || Pending installation in Rehau, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1770 Tannenberg03] || 60:E3:27:2A:58:E4 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || Pending installation in Rehau, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1751 AHKRockenbrunner1] || A0:F3:C1:76:4F:20 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=860 AHKRockenbrunner2] || C0:4A:00:0B:A8:94 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=856 AHKRockenbrunner3] || C4:6E:1F:F5:F4:AC || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1861 AHKRockenbrunner4] || 30:B5:C2:81:08:DA || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1650 OBT1] || 14cc2030e9ce || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1651 OBT2] || 14CC2030EA0C || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1659 OBT3] || 30B5C2D9B4AE || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1781 OBT4] || 30B5C2D9BD72 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1782 OBT5] || 30B5C2D9B522 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1842 ap1.refugees.kleinheubach] || 30:B5:C2:B0:56:0E || [https://netmon.freifunk-franken.de/user.php?user_id=446 oswald] || 30.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1847 stein-knauppstr-01] || C46E1F3B4262 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1845 stein-knauppstr-02] || E894F66D16A2 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1844 stein-knauppstr-03] || E894F6B981F6 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1848 stein-knauppstr-04] || 10FEEDCD9B3C || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1904 AsylcenterEbelsbach] || 30B5C2E301A6 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1319 AsylcenterEbelsbach1] || 30B5C2CB356C || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1591 refugees21.wue] || 68:72:51:2c:2f:9c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1602 refugees22.wue] || 12:bc:f9:69:d3:5c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1610 refugees23.wue] || 68:72:51:2c:30:bb || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2005 wue.N2N-ev.refugees.aux.001] || 60:e3:27:bd:ce:08 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2004 wue.N2N-ev.refugees.aux.002] || 60:e3:27:c7:30:3c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1819 wue.N2N-ev.refugees.aux.003] || 60:e3:27:c7:2f:d6 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|}<br />
<br />
Mehr Infos über die Aux-Firmware [https://wiki.freifunk-franken.de/w/Was_ist_die_aux_Firmware hier.]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Liste_bekannter_Aux-FW_Router&diff=5165
Liste bekannter Aux-FW Router
2015-12-22T08:06:50Z
<p>Green: </p>
<hr />
<div>Um den Überblick über die mit Aux-FW geflashten Router zu behalten, wird eine Übersichtstabelle über die bekannten (d.h. zurückgemeldeten) Router geführt.<br />
<br />
{|<br />
! Routername !! Router-MAC !! gemeldet von !! gemeldet am !! Bemerkungen<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1317 Notunterkunft Turnhalle] || 14CC204D4786 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1318 Notunterkunft Turnhalle1] || 30B5C2AC26D8 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1355 ArnsteinerNetz0001] || 30:b5:c2:bd:77:ba || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1716 ArnsteinerNetz0002] || 30.b5:c2:bd:78:86 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1484 ArnsteinerNetz0005] || 30:b5:c2:88:47:14 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1754 ArnsteinerNetz0006] || 30:b5:c2:88:4e:00 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1248 ArnsteinerNetz002] || 30:b5:c2:d9:c8:ae || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1247 ArnsteinerNetz003] || 30:b5:c2:d9:c8:18 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1753 ArnsteinerNetz004] || 30:b5:c2:d9:c6:de || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || reiner AP, kein Mesh, Clientzählung durch Meshrouter "ArnsteinerNetz002" 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=583 WS13W01WR1043] || e8:de:27:fd:2b:aa || [https://netmon.freifunk-franken.de/user.php?user_id=6 delphiN] || 03.11.2015 || Beta 2 Testbetrieb<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1768 HabuRef01] || 30B5C20E8AE0 || [https://netmon.freifunk-franken.de/user.php?user_id=438 DerMichy] || 15.11.2015 || Pending installation in Hammelburg, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1766 Tannenberg01] || 60:E3:27:2A:56:46 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || Pending installation in Rehau, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1769 Tannenberg02] || 30:B5:C2:E2:FD:EE || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || Pending installation in Rehau, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1770 Tannenberg03] || 60:E3:27:2A:58:E4 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || Pending installation in Rehau, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1751 AHKRockenbrunner1] || A0:F3:C1:76:4F:20 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=860 AHKRockenbrunner2] || C0:4A:00:0B:A8:94 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=856 AHKRockenbrunner3] || C4:6E:1F:F5:F4:AC || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1861 AHKRockenbrunner4] || 30:B5:C2:81:08:DA || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1650 OBT1] || 14cc2030e9ce || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1651 OBT2] || 14CC2030EA0C || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1659 OBT3] || 30B5C2D9B4AE || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1781 OBT4] || 30B5C2D9BD72 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1782 OBT5] || 30B5C2D9B522 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1842 ap1.refugees.kleinheubach] || 30:B5:C2:B0:56:0E || [https://netmon.freifunk-franken.de/user.php?user_id=446 oswald] || 30.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1847 stein-knauppstr-01] || C46E1F3B4262 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1845 stein-knauppstr-02] || E894F66D16A2 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1844 stein-knauppstr-03] || E894F6B981F6 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1848 stein-knauppstr-04] || 10FEEDCD9B3C || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || <br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1904 AsylcenterEbelsbach] || 30B5C2E301A6 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1319 AsylcenterEbelsbach1] || 30B5C2CB356C || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1591 refugees21.wue] || 68:72:51:2c:2f:9c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1602 refugees22.wue] || 12:bc:f9:69:d3:5c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1610 refugees23.wue] || 68:72:51:2c:30:bb || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2005 wue.N2N-ev.refugees.aux.001] || 60:e3:27:bd:ce:08 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2004 wue.N2N-ev.refugees.aux.002] || 60:e3:27:c7:30:3c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1819 wue.N2N-ev.refugees.aux.003] || 60:e3:27:c7:2f:d6 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|}<br />
<br />
Mehr Infos über die Aux-Firmware [https://wiki.freifunk-franken.de/w/Was_ist_die_aux_Firmware hier.]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Liste_bekannter_Aux-FW_Router&diff=5164
Liste bekannter Aux-FW Router
2015-12-22T08:02:03Z
<p>Green: </p>
<hr />
<div>Um den Überblick über die mit Aux-FW geflashten Router zu behalten, wird eine Übersichtstabelle über die bekannten (d.h. zurückgemeldeten) Router geführt.<br />
<br />
{|<br />
! Routername !! Router-MAC !! gemeldet von !! gemeldet am !! Bemerkungen<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1317 Notunterkunft Turnhalle] || 14CC204D4786 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1318 Notunterkunft Turnhalle1] || 30B5C2AC26D8 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 03.11.2015 || -<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1355 ArnsteinerNetz0001] || 30:b5:c2:bd:77:ba || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1716 ArnsteinerNetz0002] || 30.b5:c2:bd:78:86 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1484 ArnsteinerNetz0005] || 30:b5:c2:88:47:14 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1754 ArnsteinerNetz0006] || 30:b5:c2:88:4e:00 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1248 ArnsteinerNetz002] || 30:b5:c2:d9:c8:ae || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1247 ArnsteinerNetz003] || 30:b5:c2:d9:c8:18 || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1753 ArnsteinerNetz004] || 30:b5:c2:d9:c6:de || [https://netmon.freifunk-franken.de/user.php?user_id=431 ArnsteinerNetz] || 07.11.2015 || reiner AP, kein Mesh, Clientzählung durch Meshrouter "ArnsteinerNetz002" 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=583 WS13W01WR1043] || e8:de:27:fd:2b:aa || [https://netmon.freifunk-franken.de/user.php?user_id=6 delphiN] || 03.11.2015 || Beta 2 Testbetrieb<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1768 HabuRef01] || 30B5C20E8AE0 || [https://netmon.freifunk-franken.de/user.php?user_id=438 DerMichy] || 15.11.2015 || Pending installation in Hammelburg, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1766 Tannenberg01] || 60:E3:27:2A:56:46 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || Pending installation in Rehau, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1769 Tannenberg02] || 30:B5:C2:E2:FD:EE || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || Pending installation in Rehau, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1770 Tannenberg03] || 60:E3:27:2A:58:E4 || [https://netmon.freifunk-franken.de/user.php?user_id=467 Openreh] || 15.11.2015 || Pending installation in Rehau, Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1751 AHKRockenbrunner1] || A0:F3:C1:76:4F:20 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=860 AHKRockenbrunner2] || C0:4A:00:0B:A8:94 || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=856 AHKRockenbrunner3] || C4:6E:1F:F5:F4:AC || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1861 AHKRockenbrunner4] || 30:B5:C2:81:08:DA || [https://netmon.freifunk-franken.de/user.php?user_id=206 mgadmin] || 18.11.2015 || Pending Installation Diepersdorf Anf. Dez.<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1650 OBT1] || 14cc2030e9ce || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1651 OBT2] || 14CC2030EA0C || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1659 OBT3] || 30B5C2D9B4AE || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1781 OBT4] || 30B5C2D9BD72 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1782 OBT5] || 30B5C2D9B522 || [https://netmon.freifunk-franken.de/user.php?user_id=98 jujkrause] || 27.11.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1842 ap1.refugees.kleinheubach] || 30:B5:C2:B0:56:0E || [https://netmon.freifunk-franken.de/user.php?user_id=446 oswald] || 30.11.2015 || 0.5.1<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1847 stein-knauppstr-01] || C46E1F3B4262 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1845 stein-knauppstr-02] || E894F66D16A2 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1844 stein-knauppstr-03] || E894F6B981F6 || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1848 stein-knauppstr-04] || 10FEEDCD9B3C || [https://netmon.freifunk-franken.de/user.php?user_id=324 green] || 01.12.2015 || Est. start in Dec'15<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1904 AsylcenterEbelsbach] || 30B5C2E301A6 || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1319 AsylcenterEbelsbach1] || 30B5C2CB356C || [https://netmon.freifunk-franken.de/user.php?user_id=158 Moexe] || 08.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1591 refugees21.wue] || 68:72:51:2c:2f:9c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1602 refugees22.wue] || 12:bc:f9:69:d3:5c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1610 refugees23.wue] || 68:72:51:2c:30:bb || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2005 wue.N2N-ev.refugees.aux.001] || 60:e3:27:bd:ce:08 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=2004 wue.N2N-ev.refugees.aux.002] || 60:e3:27:c7:30:3c || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|-<br />
|[https://netmon.freifunk-franken.de/router.php?router_id=1819 wue.N2N-ev.refugees.aux.003] || 60:e3:27:c7:2f:d6 || [https://netmon.freifunk-franken.de/user.php?user_id=439 phry] || 21.12.2015 ||<br />
|}<br />
<br />
Mehr Infos über die Aux-Firmware [https://wiki.freifunk-franken.de/w/Was_ist_die_aux_Firmware hier.]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Impressum&diff=5080
Impressum
2015-12-13T15:41:32Z
<p>Green: /* Impressum */</p>
<hr />
<div><br />
= Allgemeine Freifunk Anfragen =<br />
Bitte verwende für allgemeine Anfragen unsere [[Portal:Kommunikation|Kontaktmöglichkeiten]].<br />
<br />
= Impressum =<br />
<br />
== Angaben gemäß § 5 TMG ==<br />
Förderverein Freie Netzwerke e. V. <br /><br />
Abteilung: Freifunk Franken <br /><br />
c/o Rabener/Rau <br /><br />
Stephanstr. 10 <br /><br />
10559 Berlin<br />
<br />
== Vertreten durch den Vorstand ==<br />
Monic Meisel <br /><br />
Iris Rabener <br /><br />
Andreas Bräu <br /><br />
Christian Heise <br />
<br />
== Kontakt ==<br />
Telefon: +49 (0)30 53014673 <br /><br />
E-Mail: mail{at}foerderverein.freie-netzwerke.de <br /><br />
E-Mail Franken: fragen{at}freifunk-franken.de<br />
<br />
== Registereintrag ==<br />
Registergericht: Amtsgericht Berlin Charlottenburg <br /><br />
Registernummer: VR 22961<br />
<br />
== Verantwortlich für den Inhalt nach § 55 Abs. 2 RStV ==<br />
Dr. Olaf Koglin <br /><br />
Rechtsanwalt <br /><br />
An der Aussicht 40 <br /><br />
13503 Berlin<br />
<br />
== Haftung für Inhalte ==<br />
Die Inhalte unserer Seiten wurden mit größter Sorgfalt erstellt. Für die Richtigkeit, Vollständigkeit und Aktualität der Inhalte können wir jedoch keine Gewähr übernehmen. Als Diensteanbieter sind wir gemäß § 7 Abs.1 TMG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 TMG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen. Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden von entsprechenden Rechtsverletzungen werden wir diese Inhalte umgehend entfernen.<br />
<br />
== Haftung für Links ==<br />
Unser Angebot enthält Links zu externen Webseiten Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar. Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen.<br />
<br />
== Urheberrecht ==<br />
Die durch die Seitenbetreiber erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Die Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechtes bedürfen der schriftlichen Zustimmung des jeweiligen Autors bzw. Erstellers. Downloads und Kopien dieser Seite sind nur für den privaten, nicht kommerziellen Gebrauch gestattet. Soweit die Inhalte auf dieser Seite nicht vom Betreiber erstellt wurden, werden die Urheberrechte Dritter beachtet. Insbesondere werden Inhalte Dritter als solche gekennzeichnet. Sollten Sie trotzdem auf eine Urheberrechtsverletzung aufmerksam werden, bitten wir um einen entsprechenden Hinweis. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Inhalte umgehend entfernen.<br />
<br />
== Datenschutz ==<br />
Die Nutzung unserer Webseite ist in der Regel ohne Angabe personenbezogener Daten möglich. Soweit auf unseren Seiten personenbezogene Daten (beispielsweise Name, Anschrift oder eMail-Adressen) erhoben werden, erfolgt dies, soweit möglich, stets auf freiwilliger Basis. Diese Daten werden ohne Ihre ausdrückliche Zustimmung nicht an Dritte weitergegeben.<br />
<br />
Wir weisen darauf hin, dass die Datenübertragung im Internet (z.B. bei der Kommunikation per E-Mail) Sicherheitslücken aufweisen kann. Ein lückenloser Schutz der Daten vor dem Zugriff durch Dritte ist nicht möglich.<br />
<br />
Der Nutzung von im Rahmen der Impressumspflicht veröffentlichten Kontaktdaten durch Dritte zur Übersendung von nicht ausdrücklich angeforderter Werbung und Informationsmaterialien wird hiermit ausdrücklich widersprochen. Die Betreiber der Seiten behalten sich ausdrücklich rechtliche Schritte im Falle der unverlangten Zusendung von Werbeinformationen, etwa durch Spam-Mails, vor.</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Impressum&diff=5079
Impressum
2015-12-13T15:22:42Z
<p>Green: /* Kontakt */</p>
<hr />
<div><br />
= Allgemeine Freifunk Anfragen =<br />
Bitte verwende für allgemeine Anfragen unsere [[Portal:Kommunikation|Kontaktmöglichkeiten]].<br />
<br />
= Impressum =<br />
<br />
== Angaben gemäß § 5 TMG ==<br />
Förderverein Freie Netzwerke e. V. <br /><br />
Abteilung: Freifunk Franken <br /><br />
c/o Rabener/Rau <br /><br />
Stephanstr. 10 <br /><br />
10559 Berlin<br />
<br />
== Vertreten durch den Vorstand ==<br />
Monic Meisel <br /><br />
Iris Rabener <br /><br />
Andreas Bräu <br /><br />
Christian Heise <br />
<br />
== Kontakt ==<br />
Telefon: +49 (0)30 53014673 <br /><br />
E-Mail: mail{at}foerderverein.freie-netzwerke.de <br /><br />
E-Mail Franken: fragen{at}freifunk-franken.de<br />
<br />
== Verantwortlich für den Inhalt nach § 55 Abs. 2 RStV ==<br />
Dr. Olaf Koglin <br /><br />
Rechtsanwalt <br /><br />
An der Aussicht 40 <br /><br />
13503 Berlin<br />
<br />
== Haftung für Inhalte ==<br />
Die Inhalte unserer Seiten wurden mit größter Sorgfalt erstellt. Für die Richtigkeit, Vollständigkeit und Aktualität der Inhalte können wir jedoch keine Gewähr übernehmen. Als Diensteanbieter sind wir gemäß § 7 Abs.1 TMG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 TMG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen. Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden von entsprechenden Rechtsverletzungen werden wir diese Inhalte umgehend entfernen.<br />
<br />
== Haftung für Links ==<br />
Unser Angebot enthält Links zu externen Webseiten Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar. Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen.<br />
<br />
== Urheberrecht ==<br />
Die durch die Seitenbetreiber erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Die Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechtes bedürfen der schriftlichen Zustimmung des jeweiligen Autors bzw. Erstellers. Downloads und Kopien dieser Seite sind nur für den privaten, nicht kommerziellen Gebrauch gestattet. Soweit die Inhalte auf dieser Seite nicht vom Betreiber erstellt wurden, werden die Urheberrechte Dritter beachtet. Insbesondere werden Inhalte Dritter als solche gekennzeichnet. Sollten Sie trotzdem auf eine Urheberrechtsverletzung aufmerksam werden, bitten wir um einen entsprechenden Hinweis. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Inhalte umgehend entfernen.<br />
<br />
== Datenschutz ==<br />
Die Nutzung unserer Webseite ist in der Regel ohne Angabe personenbezogener Daten möglich. Soweit auf unseren Seiten personenbezogene Daten (beispielsweise Name, Anschrift oder eMail-Adressen) erhoben werden, erfolgt dies, soweit möglich, stets auf freiwilliger Basis. Diese Daten werden ohne Ihre ausdrückliche Zustimmung nicht an Dritte weitergegeben.<br />
<br />
Wir weisen darauf hin, dass die Datenübertragung im Internet (z.B. bei der Kommunikation per E-Mail) Sicherheitslücken aufweisen kann. Ein lückenloser Schutz der Daten vor dem Zugriff durch Dritte ist nicht möglich.<br />
<br />
Der Nutzung von im Rahmen der Impressumspflicht veröffentlichten Kontaktdaten durch Dritte zur Übersendung von nicht ausdrücklich angeforderter Werbung und Informationsmaterialien wird hiermit ausdrücklich widersprochen. Die Betreiber der Seiten behalten sich ausdrücklich rechtliche Schritte im Falle der unverlangten Zusendung von Werbeinformationen, etwa durch Spam-Mails, vor.</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Impressum&diff=5078
Impressum
2015-12-13T15:19:31Z
<p>Green: /* Angaben gemäß § 5 TMG */</p>
<hr />
<div><br />
= Allgemeine Freifunk Anfragen =<br />
Bitte verwende für allgemeine Anfragen unsere [[Portal:Kommunikation|Kontaktmöglichkeiten]].<br />
<br />
= Impressum =<br />
<br />
== Angaben gemäß § 5 TMG ==<br />
Förderverein Freie Netzwerke e. V. <br /><br />
Abteilung: Freifunk Franken <br /><br />
c/o Rabener/Rau <br /><br />
Stephanstr. 10 <br /><br />
10559 Berlin<br />
<br />
== Vertreten durch den Vorstand ==<br />
Monic Meisel <br /><br />
Iris Rabener <br /><br />
Andreas Bräu <br /><br />
Christian Heise <br />
<br />
== Kontakt ==<br />
Telefon: +49 (0)30 53014673 <br /><br />
E-Mail: mail{at}foerderverein.freie-netzwerke.de <br /><br />
E-Mail Franken: fragen@freifunk-franken.de <br />
<br />
== Verantwortlich für den Inhalt nach § 55 Abs. 2 RStV ==<br />
Dr. Olaf Koglin <br /><br />
Rechtsanwalt <br /><br />
An der Aussicht 40 <br /><br />
13503 Berlin<br />
<br />
== Haftung für Inhalte ==<br />
Die Inhalte unserer Seiten wurden mit größter Sorgfalt erstellt. Für die Richtigkeit, Vollständigkeit und Aktualität der Inhalte können wir jedoch keine Gewähr übernehmen. Als Diensteanbieter sind wir gemäß § 7 Abs.1 TMG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 TMG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen. Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden von entsprechenden Rechtsverletzungen werden wir diese Inhalte umgehend entfernen.<br />
<br />
== Haftung für Links ==<br />
Unser Angebot enthält Links zu externen Webseiten Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar. Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen.<br />
<br />
== Urheberrecht ==<br />
Die durch die Seitenbetreiber erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Die Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechtes bedürfen der schriftlichen Zustimmung des jeweiligen Autors bzw. Erstellers. Downloads und Kopien dieser Seite sind nur für den privaten, nicht kommerziellen Gebrauch gestattet. Soweit die Inhalte auf dieser Seite nicht vom Betreiber erstellt wurden, werden die Urheberrechte Dritter beachtet. Insbesondere werden Inhalte Dritter als solche gekennzeichnet. Sollten Sie trotzdem auf eine Urheberrechtsverletzung aufmerksam werden, bitten wir um einen entsprechenden Hinweis. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Inhalte umgehend entfernen.<br />
<br />
== Datenschutz ==<br />
Die Nutzung unserer Webseite ist in der Regel ohne Angabe personenbezogener Daten möglich. Soweit auf unseren Seiten personenbezogene Daten (beispielsweise Name, Anschrift oder eMail-Adressen) erhoben werden, erfolgt dies, soweit möglich, stets auf freiwilliger Basis. Diese Daten werden ohne Ihre ausdrückliche Zustimmung nicht an Dritte weitergegeben.<br />
<br />
Wir weisen darauf hin, dass die Datenübertragung im Internet (z.B. bei der Kommunikation per E-Mail) Sicherheitslücken aufweisen kann. Ein lückenloser Schutz der Daten vor dem Zugriff durch Dritte ist nicht möglich.<br />
<br />
Der Nutzung von im Rahmen der Impressumspflicht veröffentlichten Kontaktdaten durch Dritte zur Übersendung von nicht ausdrücklich angeforderter Werbung und Informationsmaterialien wird hiermit ausdrücklich widersprochen. Die Betreiber der Seiten behalten sich ausdrücklich rechtliche Schritte im Falle der unverlangten Zusendung von Werbeinformationen, etwa durch Spam-Mails, vor.</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Impressum&diff=5077
Impressum
2015-12-13T15:19:14Z
<p>Green: /* Impressum */</p>
<hr />
<div><br />
= Allgemeine Freifunk Anfragen =<br />
Bitte verwende für allgemeine Anfragen unsere [[Portal:Kommunikation|Kontaktmöglichkeiten]].<br />
<br />
= Impressum =<br />
<br />
== Angaben gemäß § 5 TMG ==<br />
Förderverein Freie Netzwerke e. V. <br /><br />
Abteilung: '''Freifunk Franken''' <br /><br />
c/o Rabener/Rau <br /><br />
Stephanstr. 10 <br /><br />
10559 Berlin<br />
<br />
== Vertreten durch den Vorstand ==<br />
Monic Meisel <br /><br />
Iris Rabener <br /><br />
Andreas Bräu <br /><br />
Christian Heise <br />
<br />
== Kontakt ==<br />
Telefon: +49 (0)30 53014673 <br /><br />
E-Mail: mail{at}foerderverein.freie-netzwerke.de <br /><br />
E-Mail Franken: fragen@freifunk-franken.de <br />
<br />
== Verantwortlich für den Inhalt nach § 55 Abs. 2 RStV ==<br />
Dr. Olaf Koglin <br /><br />
Rechtsanwalt <br /><br />
An der Aussicht 40 <br /><br />
13503 Berlin<br />
<br />
== Haftung für Inhalte ==<br />
Die Inhalte unserer Seiten wurden mit größter Sorgfalt erstellt. Für die Richtigkeit, Vollständigkeit und Aktualität der Inhalte können wir jedoch keine Gewähr übernehmen. Als Diensteanbieter sind wir gemäß § 7 Abs.1 TMG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 TMG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen. Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden von entsprechenden Rechtsverletzungen werden wir diese Inhalte umgehend entfernen.<br />
<br />
== Haftung für Links ==<br />
Unser Angebot enthält Links zu externen Webseiten Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar. Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen.<br />
<br />
== Urheberrecht ==<br />
Die durch die Seitenbetreiber erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Die Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechtes bedürfen der schriftlichen Zustimmung des jeweiligen Autors bzw. Erstellers. Downloads und Kopien dieser Seite sind nur für den privaten, nicht kommerziellen Gebrauch gestattet. Soweit die Inhalte auf dieser Seite nicht vom Betreiber erstellt wurden, werden die Urheberrechte Dritter beachtet. Insbesondere werden Inhalte Dritter als solche gekennzeichnet. Sollten Sie trotzdem auf eine Urheberrechtsverletzung aufmerksam werden, bitten wir um einen entsprechenden Hinweis. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Inhalte umgehend entfernen.<br />
<br />
== Datenschutz ==<br />
Die Nutzung unserer Webseite ist in der Regel ohne Angabe personenbezogener Daten möglich. Soweit auf unseren Seiten personenbezogene Daten (beispielsweise Name, Anschrift oder eMail-Adressen) erhoben werden, erfolgt dies, soweit möglich, stets auf freiwilliger Basis. Diese Daten werden ohne Ihre ausdrückliche Zustimmung nicht an Dritte weitergegeben.<br />
<br />
Wir weisen darauf hin, dass die Datenübertragung im Internet (z.B. bei der Kommunikation per E-Mail) Sicherheitslücken aufweisen kann. Ein lückenloser Schutz der Daten vor dem Zugriff durch Dritte ist nicht möglich.<br />
<br />
Der Nutzung von im Rahmen der Impressumspflicht veröffentlichten Kontaktdaten durch Dritte zur Übersendung von nicht ausdrücklich angeforderter Werbung und Informationsmaterialien wird hiermit ausdrücklich widersprochen. Die Betreiber der Seiten behalten sich ausdrücklich rechtliche Schritte im Falle der unverlangten Zusendung von Werbeinformationen, etwa durch Spam-Mails, vor.</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Firmwareinstallation/UbiquitiPicoStationM2HP&diff=5068
Firmwareinstallation/UbiquitiPicoStationM2HP
2015-12-12T10:43:33Z
<p>Green: /* Installation der Freifunk Firmware */</p>
<hr />
<div>{{Entwurf}}<br />
__TOC__<br />
<br />
= Installationsanleitung für die Ubiquiti PicoStation M2HP und die Ubiquiti NanoStation Loco M2 =<br />
<br />
''Da die PicoStation und die Nanostation intern die gleiche Technik verwenden, gilt diese Anleitung sowohl für die PicoStation M2HP als auch für die NanoStation Loco M2 von Ubiquity. PicoStation und NanoStation können in dieser Anleitung also synonym verstanden werden.''<br />
<br />
== Voraussetzungen ==<br />
<br />
Zur erstmaligen Einrichtung werden zusätzlich zum Gerät zwei Netzwerkkabel benötigt.<br />
<br />
Ein Netzwerkkabel um dem Gerät auch Strom zu geben und das 2. um das Gerät mit einem PC/Laptop zu verbinden um es zu flashen.<br />
<br />
== Lieferumfang ==<br />
<br />
[[Datei:UbiquitiPicoStationM2HP12.JPG|600px|Ubiquiti PicoStation M2HP Lieferumfang]]<br />
<br />
Die PicoStation wird mit folgenden Dingen ausgeliefert:<br />
<br />
* 1 Picostation<br />
* 2 Antenne<br />
* 3 Netzteil<br />
* 4 Stromkabel<br />
* 5 Wandhalterung<br />
* 6 Schrauben für Wandhalterung<br />
* 7 Kabelbinder zum befestigen der PicoStation mit der Wandhalterung<br />
* 8 Kurzanleitung<br />
<br />
== zusätzlich benötigte Hardware ==<br />
<br />
Nicht im Lieferumfang enthalten sind Netzwerkkabel. Für die Stromversorgung wird mindestens ein Netzwerkkabel benötigt (das Netzteil ist ein POE-Netzteil). Je nach Einsatzzweck benötigt man ein zweites. Dieses wird auch zum Flashen benötigt. Wenn man die PicoStation zur Einwahl in das Freifunk-Netz oder direkt per Kabel mit einem weiteren Freifunkrouter mittels B.A.T.M.A.N. verbinden möchte.<br />
<br />
== Installation der Freifunk Firmware ==<br />
<br />
Für die PicoStation kann die gleiche Firmware wie für die NanoStation verwendet werden. Die aktuelle Version der Firmware [https://dev.freifunk-franken.de/firmware/dev/20150000_reddog/ubnt/ liegt hier zum Download bereit].<br />
<br />
Zum Flashen der Originalfirmware benötigt man die Datei "openwrt-ar71xx-generic-ubnt-nano-m-squashfs-factory.bin".<br />
<br />
<div style="margin-bottom:1em; padding:1em 1em 0.5em 1em; border:2px solid #dc0067;color:#000;"><br />
<b>Achtung! </b><br />
<br />
Bei der Installation einer Nanostation oder Picostation sind momentan zwei Dinge zu beachten:<br />
<br />
Zum einen muss vor der Installation die Firmwareversion der original Firmware airOS geachtet werden (unter dem Reiter "System" zu finden), ist die noch 5.5.X kann problemlos installiert werden, ab Version 5.6.X macht man sich mit der Installation die Nanostation unbrauchbar (Vgl. https://wiki.openwrt.org/toh/ubiquiti/airmaxm). Ist eine airOS 5.6.X installiert, muss diese bevor installiert werden kann durch eine ältere Version (5.5.X) von airOS ersetzt werden.<br />
</div><br />
<br />
=== IP-Konfiguration ===<br />
<br />
Eine neue PicoStation hat im Auslieferungszustand die IP "192.168.1.20". Zum Übermitteln der Firmware kann man sich eine IP-Adresse aus dem selben Adressraum zuweisen z.B.:<br />
<br />
* IP: 192.168.1.11<br />
* Subnetz-Maske: 255.255.255.0<br />
<br />
=== Kabelverbindung ===<br />
<br />
Das erste Netzwerkkabel wird von eurem Rechner mit der "LAN"-Buchse des Netzteils verbunden. Das zweite Netzwerkkabel wird mit der "POE"-Buchse des Netzteils und der PicoStation verbunden.<br />
<br />
=== Anmelden an PicoStation (Originalfirmware) ===<br />
<br />
Um sich an der PicoStation anzumelden muss man die folgende Seite aufrufen:<br />
<br />
[https://192.168.1.20 https://192.168.1.20]<br />
<br />
Die Meldung des Zertifikatsfehlers kann man ignorieren und (je nach Browser unterschiedlich) akzeptieren dass man sich dennoch damit verbinden möchte.<br />
<br />
Zum Anmelden verwendet man folgende Daten:<br />
<br />
* Username: ubnt<br />
* Password: ubnt<br />
<br />
und wählt anschließend eine "Country" sowie "Language" aus und setzt noch die Option "I agree ..." bevor man die Eingaben mit "Login" bestätigt.<br />
<br />
[[Datei:UbiquitiPicoStationM2HP01.png|600px|Ubiquiti PicoStation M2HP Login]]<br />
<br />
=== Firmware hochladen und einspielen ===<br />
<br />
Um die Freifunk Firmware einzuspielen wählt man zuerst den Reiter "System" aus.<br />
<br />
[[Datei:UbiquitiPicoStationM2HP02.png|600px|Ubiquiti PicoStation M2HP Firmware System]]<br />
<br />
Anschließend klickt man auf den Button "Choose File" <br />
<br />
[[Datei:UbiquitiPicoStationM2HP03.png|600px|Ubiquiti PicoStation M2HP Firmware Choose File]]<br />
<br />
und wählt die vorher heruntergeladene Firmware-Datei aus.<br />
<br />
[[Datei:UbiquitiPicoStationM2HP04.png|600px|Ubiquiti PicoStation M2HP Firmware Select File]]<br />
<br />
Die Auswahl kann man nun mit dem Button "Upload" bestätigen.<br />
<br />
[[Datei:UbiquitiPicoStationM2HP05.png|600px|Ubiquiti PicoStation M2HP Firmware Upload]]<br />
<br />
Es erscheint eine Warnung dass die Firmware von einem Drittanbieter ist und man muss den Upload mit einem Klick auf den Button "Update" bestätigen.<br />
<br />
[[Datei:UbiquitiPicoStationM2HP06.png|600px|Ubiquiti PicoStation M2HP Firmware Update]]<br />
<br />
Dann heisst es warten ...<br />
<br />
[[Datei:UbiquitiPicoStationM2HP07.png|600px|Ubiquiti PicoStation M2HP Upload Processs]]<br />
<br />
Die Seite macht nach einer gewissen Zeit einen automatischen Refresh der Seite und läuft (durch die neue Firmware) ins Leere. Dann ist ein guter Zeitpunkt das Netzwerkkabel vom "LAN"-Port des Netzteils zu entfernen.<br />
<br />
Nun verbindet sich die neu geflashte PicoStation über eventuell schon vorhandene Freifunk Router mit dem Netmon und man kann darauf warten, dass das Gerät in der Übersicht der [https://netmon.freifunk-franken.de/routers_trying_to_assign.php Liste der neuen Router] erscheint.<br />
<br />
== Funktionsweise der LAN-Schnittstelle ändern ==<br />
<br />
Da das Gerät nur eine LAN-Schnittstelle hat muss man sich entscheiden welche Funktion diese haben soll. Nach dem Einspielen der Firmware ist B.A.T.M.A.N. darauf konfiguriert.<br />
<br />
Um die Einstellung zu ändern muss man sich via SSH auf [[Anleitungen#Wie_kann_ich_mich_auf_den_Router_einloggen.3F| das Gerät verbinden.]] Das funktioniert auch wenn die PicoStation noch keine Verbindung zum Freifunk-Netz hat. Allerdings muss man dann für die SSID franken.freifunk.net manuell eine beliebige IPv4 (z.B. 1.2.3.4) und eine Netzmaske (z.B. 255.255.255.0) vorgeben und sich in Reichweite des Routers verbinden. Eine IP muss dann nicht mehr aus dem Internet bezogen werden, was eine Verbindung zur SSID franken.freifunk.net ermöglicht. Danach kann man sich über [[Anleitungen#Wie_kann_ich_mich_auf_den_Router_einloggen.3F| die IPv6 LinkLocal Adresse des Routers einloggen.]]<br />
<br />
Die Einstellungen werden in der Datei "/etc/network.mode" gemacht, die man mit Programm [http://netz10.de/2009/04/28/vi-crashkurs-fur-einsteiger| vi] bearbeiten kann.<br />
<br />
<code><br />
vi /etc/network.mode<br />
</code><br />
<br />
'''Hinweis:''' Ab Firmware V0.5.1 werden die Nezwerkmodi in "/etc/network.mode" konfiguriert. Diese Konfiguration bleibt ab V0.5.1 bei späteren Firmware-Updates erhalten. Bis Firmware V0.5 wurden die Netzwerkmodi in "/etc/network.nanostation-m" konfiguriert, wobei die Konfiguration bei einem Update nicht übernommen wird.<br />
<br />
[[Datei:Ubiquiti-Installationsnleitung_WAN_Step1.png|Ubiquiti PicoStation M2HP Edit Network Port]]<br />
<br />
In der Konfigurationsdatei ist es eigentlich selbsterklärend dokumentiert. Nehmt euch die Zeit und lest euch diese in Ruhe durch.<br />
<br />
[[Datei:Ubiquiti-Installationsnleitung_WAN_Step2.png|Ubiquiti PicoStation M2HP Default Network Config]]<br />
<br />
Um die LAN-Schnittstelle auf die WAN-Funktion umzustellen muss man also im Absatz nach "connect with fastd vpn" die Kommentarzeichen entfernen und die Zeile nach "directly connect to other mesh nodes - this is the default" auskommentieren.<br />
<br />
[[Datei:Ubiquiti-Installationsnleitung_WAN_Step3.png|Ubiquiti PicoStation M2HP WAN Network Config]]<br />
<br />
Abschließend speichert man die Datei und kann "vi" schließen.<br />
Dies geht durch drücken der ESC-Taste. Anschließend muss man ":wg" eingeben und mit ENTER bestätigen<br />
<br />
<code><br />
[ESC] :wq [ENTER]<br />
</code><br />
<br />
Um alle Änderungen zu übernehmen müssen noch folgende Befehle ausgeführt werden.<br />
<br />
<code><br />
cp /rom/etc/sysctl.conf /etc/sysctl.conf<br />
<br />
cp /rom/etc/config/network /etc/config/network<br />
<br />
reboot & exit<br />
</code><br />
<br />
<br />
[[Datei:Ubiquiti-Installationsnleitung_WAN_Step4.png|Ubiquiti PicoStation M2HP WAN Network Config]]<br />
<br />
[[Kategorie:EinstiegsInformationen]]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Portal:Firmware_OUT&diff=5054
Portal:Firmware OUT
2015-12-10T18:20:08Z
<p>Green: /* Registrierung/Übernahme im Netmon */</p>
<hr />
<div>= Firmware =<br />
Aktuell ist die Version 0.5.1. https://dev.freifunk-franken.de/firmware/<br />
<br />
Eine Anleitung wie die aktuellen Firmware gebaut wird oder an der Entwicklung teilgenommen werden kann gibt es [[FirmwareEntwicklung|hier]].<br />
<br />
'''Tipp:''' Die Inbetriebnahme eines mit FF-Firmware geflashten Router/Registrierung zum Weitergeben/Ausdrucken als [[media:Anleitung_zur_Inbetriebnahme_eines_Freifunkrouters.pdf|PDF]].<br />
<br />
== Anleitung zur Routerinstallation ==<br />
<br />
für WR841N(D) WR1043N(D)<br />
<br />
=== Auspacken ===<br />
[[Datei:dein_router.jpg|400px|thumb|Lieferinhalt]]<br />
<br />
* Router (1) auspacken, Teile auf Vollständigkeit überprüfen<br />
* falls die Antenne (2) noch nicht angeschlossen ist, schraubt man diese jetzt an<br />
* das Netzteil (3) für die Stromversorgung des Routers und das LAN-Kabel (4) braucht man später<br />
** Es sollte immer das original Netzteil verwendet werden um Probleme wärend dem Flshen zu vermeiden.<br />
<br />
=== Firmware (Erst-)Installation ===<br />
[[Datei:TP_link_version.jpg|400px|thumb|Router Rückseite]]<br />
<br />
* Hier eine [[Portal:Hardware|Liste]], welche Routertypen für die Freifunk-Franken-Firmware geeignet sind<br />
* Herauszufinden, welche Firmware man braucht, ist ganz einfach: der Routertyp (1) und die Hardwareversion (2) stehen auf der Unterseite des Routers.<br />
* Die passende aktuelle Firmware [https://dev.freifunk-franken.de/firmware/current/ hier] herunterladen.<br />
** Die '''Factory'''-Version ist zu verwenden, wenn vorher noch keine Freifunk-Firmware installiert war.<br />
** Die '''Sysupgrade'''-Version braucht man nur, wenn bereits eine Freifunk-Firmware installiert ist.<br />
<br />
<div style="border:1px solid black;"><br />
'''Achtung!''' <br />
Die Firmware für den WR841ND V7 (und nur genau für diesen) ist kaputt. Hier sollte [https://dev.freifunk-franken.de/firmware/dev/20150907_meskal/ diese Firmware] verwendet werden bis ein fix eingespielt wurde. Wurde die falsche Firmware bereits geflasht kann mit folgender Lösung das Problem behoben werden:<br />
* nichts am WAN Port anschließen<br />
* Kein meshfähiges Gerät in der nähe betreiben<br />
* LAN Kabel an einen gelben Port ran und probieren per Locallink drauf zu kommen, eventuell auch die letzte Ziffer der MAC +1 oder -1 rechnen (ich glaub -1) sollte eigentlich dann klappen.<br />
Folgendes Kommando dann am Router ausführen:<br />
<pre><br />
cp /etc/network.tl-wr841nd-v7 /etc/network.tl-wr841n-v7 <br />
</pre><br />
Danach rebooten und der Router sollte sich problemlos im Netmon melden.<br />
</div><br />
<br />
[[Datei:gelbe_buchse.jpg|400px|thumb|gelbe Buchse]]<br />
* den Computer z.B. mit dem beiliegenden Patchkabel an einen der LAN-Ports (gelb) des Routers anschließen<br />
* den Router an Strom anschließen und einschalten<br />
* warten, bis der eigene Computer eine gültige IP-Adresse bekommen hat (Falls dies nicht klappt, den Rechner neu starten und prüfen, ob die IP-Adresse automatisch vom Router bezogen wurde.)<br />
* im Webinterface des Routers einloggen (Nutzername und Passwort stehen auf der Unterseite des Routers; normalerweise funktioniert http://admin:admin@192.168.0.1)<br />
<br />
[[Datei:TP_link_firmware.jpg|400px|thumb|Firmware-Update]]<br />
* unter "System Tools" –> "Firmware Upgrade" die vorher heruntergeladene Firmware zum Gerät schicken<br />
* Geduldig warten, bis der Router neu startet. '''Während die Installation läuft, ziehe bitte auf keinen Fall den Stecker oder das Netzwerk-Kabel!'''<br />
* Im Webinterface kann nach dem Neustart gegebenenfalls die Fehlermeldung kommen, dass keine Verbindung möglich ist. Die neue Firmware hat kein Webinterface.<br />
* Das Passwort sollte geändert werden! Siehe [[Anleitungen|hier]].<br />
<br />
=== Registrierung/Übernahme im Netmon ===<br />
* Router nach dem Firmware Flash nicht manuell booten oder vom Strom trennen<br />
* über den WAN-Port (blau) den Router mit dem Internet verbinden (einfach von gelb auf blau umstecken oder per B.A.T.M.A.N über WLAN mit schon in der Nähe stehenden Freifunkroutern verbinden lassen)<br />
* Router sollte innerhalb der nächsten 5-10 Minuten im Netmon unter Router/Neue Router auftauchen<br />
* auf [https://netmon.freifunk-franken.de/routerlist.php Routerliste] gehen<br />
* auf "Registrieren" klicken (oben rechts)<br />
* Benutzername und Passwort ausdenken und eingeben, E-Mail eingeben, auf Registrieren klicken<br />
* wenn E-Mail da ist, Registrierung abschließen<br />
* neue Router tauchen unter "Router" (Routerliste) –> "[https://netmon.freifunk-franken.de/routers_trying_to_assign.php Neue Router]" auf<br />
* Router übernehmen und Name sowie Position auf Karte eintragen, den Router erkennt man an seiner MAC-Adresse (siehe Aufkleber Unterseite)<br />
<br />
<div style="margin-bottom:1em; padding:1em 1em 0.5em 1em; border:2px solid #dc0067;color:#000;"><br />
<b>Wichtig:</b><br/><br />
Der Ortseintrag im Netmon ist für die korrekte Funktion des Freifunknetzes von hoher Bedeutung.<br />
Das Freifunk-Franken Netz ist in verschiedene Hoods segmentiert (Vgl. [[Portal:Netz]]). Ein in die '''falsche''' Hood oder ein '''nicht''' eingetragener Router, der mit anderen Routern mesht, umgeht die beabsichtigte Segmentierung und verbindet die jeweiligen Hoods auf Level 2 Ebene miteinader, wo jediglich ein Level 3 Routing stattfinden sollte.<br />
<br />
Dies ist die momentan häufigste Ursache für Schwierigkeiten und Performance-Defizite im Freifunk Netz.<br />
<br />
Wer seinen Standort nicht bekannt geben möchte, möge ihn auf der Netmon Karte in der gleichen Hood, in der der Router seinen tatsächlichen Standort hat, an einem beliebigen anderen Ort platzieren.<br />
<br />
Die Aufteilung der Hoods kann man [https://monitoring.freifunk-franken.de/map hier] einsehen, indem man im Overlay (rechte obere Ecke) die Checkbox Hoods aktiviert. <br />
<br />
Gut geeignete Fake-Standorte sind die, die sofort als solche erkannt werden können, z.B.:<br />
* für die Fürther Hood: Mitten im Stadtparkweiher, auf der Pegnitz oder auf der Rednitz<br />
* für die Nürnberger Hood: Mitten auf dem Wöhrder See<br />
* ganz Allgemein: Flüsse, Seen, Flughafenrollbahnen, auf der Autobahnmitte, mitten auf dem Fußballplatz<br />
<br />
Die richtige Angabe des tatsächlichen Standorts erachten wir selbstverständlich für vorteilhafter. Wer keinen Standort angeben möchte, möge sich einen beliebigen innerhalb der selben Hood aussuchen.<br />
</div><br />
<br />
== Firmware-Update ==<br />
<br />
Wenn bereits eine Freifunk-Franken-Firmware auf dem Router installiert ist, geht man zum Updaten nach einer der folgenden Methoden vor:<br />
<br />
=== Möglichkeit 1: sysupgrade.sh ===<br />
'''<span style="color:#FF0000">Achtung: Funktioniert erst <u>ab</u> Firmware Version 0.5.1</span>'''<br />
* Man loggt sich auf dem Router per ssh ein, siehe auch [[Anleitungen|hier]].<br />
* Und startet folgendes Skript ''/etc/sysupgrade.sh''<br />
<br />
=== Möglichkeit 2: Skript einfügen ===<br />
* Man loggt sich auf dem Router per ssh ein, siehe auch [[Anleitungen|hier]].<br />
* Man fügt in das Fenster der Konsole dieses Skript ein und bestätigt gegebenenfalls mit [Enter]:<br />
<pre><br />
BOARD=$(cat /var/sysinfo/board_name)<br />
case "$BOARD" in<br />
tl-wr1043nd)<br />
BOARD=tl-wr1043nd-v1<br />
;;<br />
tl-wr741nd)<br />
grep "Atheros AR7240 rev 2" /proc/cpuinfo && BOARD=tl-wr741nd-v2 || BOARD=tl-wr741nd-v4<br />
;;<br />
tl-wr741nd-v4)<br />
grep 740 /var/sysinfo/model && BOARD=tl-wr740n-v4<br />
;;<br />
tl-wr841n-v7)<br />
BOARD=tl-wr841nd-v7<br />
;;<br />
tl-wr841n-v9)<br />
grep "v10" /var/sysinfo/model && BOARD=tl-wr841n-v10<br />
;;<br />
nanostation-m)<br />
BOARD=ubnt-nano-m<br />
;;<br />
tl-wdr4300)<br />
BOARD=tl-wdr4300-v1<br />
;;<br />
esac<br />
FILE="openwrt-ar71xx-generic-$BOARD-squashfs-sysupgrade.bin"<br />
echo "Loading $FILE"<br />
cd /tmp/<br />
wget http://$(uci get configurator.@api[0].ipv6_address)%$(uci get configurator.@api[0].ipv6_interface)/dev/firmware/current/${FILE}<br />
wget http://$(uci get configurator.@api[0].ipv6_address)%$(uci get configurator.@api[0].ipv6_interface)/dev/firmware/current/${FILE}.md5<br />
md5sum -c ${FILE}.md5 && sysupgrade ${FILE}<br />
</pre><br />
<br />
'''Tipp:''' Unter Windows kann der Inhalt der Zwischenablage durch [Umschalt]+[Einfg] in das PuTTY-Konsolenfenster eingefügt werden.<br />
* Bei Ubiquiti Routern ggf. manuell vorgehen (siehe Möglichkeit 3).<br />
<br />
=== Möglichkeit 3: manuelles Vorgehen ===<br />
==== unter Linux ====<br />
* Man loggt sich per ssh auf dem Router ein: <tt>ssh root@<ipv6%iface></tt>, siehe auch [[Anleitungen|hier]].<br />
* Man wechselt mit <tt>cd /tmp</tt> in das richtige Verzeichnis. Das aktuelle Verzeichnis kann man sich mit <tt>pwd</tt> anzeigen lassen.<br />
** Das Image wird auf den lokalen PC heruntergeladen und dann auf den Router hochgeladen, dazu gibst du auf deinem Rechner diesen Befehl in die Linux-Konsole ein: <tt>scp <imagename> root@[<ipv6%iface>]:/tmp</tt>, das sieht dann z.B. so aus: <tt>scp openwrt-ar71xx-generic-tl-wr741nd-v4-squashfs-sysupgrade.bin root@[fe80::fad1:11ff:fe90:3e6e%wlan0]:/tmp</tt><br />
** Alternativ erfolgt der Download direkt auf dem Router <tt>cd /tmp && wget http://[fe80::ff:feee:1%br-mesh]/dev/firmware/<version>/<image></tt>, z.B. <tt>cd /tmp && wget http://[fe80::ff:feee:1%br-mesh]/dev/firmware/0.5.1/openwrt-ar71xx-generic-tl-wr741nd-v4-squashfs-sysupgrade.bin</tt><br />
* Zuletzt führt man das Update aus: <tt>sysupgrade -n <imagename></tt>. Solange du kein sehr altes Image (vor 0.3.999) auf dem Router hast, kannst du versuchen, ohne <tt>-n</tt> zu flashen, dann bleibt das Passwort erhalten.<br />
<br />
==== unter Windows ====<br />
<br />
* Zuerst muss das Firmware-Image (bin-Datei mit dem Wert "sysupgrade" im Namen z.B. <tt>"openwrt-ar71xx-generic-ubnt-nano-m-squashfs-<span style="color:#FF0000">sysupgrade</span>.bin"</tt>) auf den Computer heruntergeladen werden.<br />
* Um die Datei auf den Router spielen zu können muss man sich zuerst mit dem Freifunk-Netz verbinden (via WLAN oder LAN).<br />
* Mit [https://winscp.net/eng/download.php WinSCP] kann man die Datei auf das Gerät kopieren.<br />
** Dazu startet man WinSCP und wählt als Übertragungsprotokoll "SCP", gibt IPv6-Adresse des Routers, sowie "root" als User und das dazugehörige Passwort ein.<br />
** [[Datei:Winscp-connection-settings.jpg]]<br />
** Dann wechselt man im linken Explorer (eigener Rechner) in das Verzeichnis wo man das Image heruntergeladen hat und im rechten Explorer in das Verzeichnis "/tmp". Dann kann man die Datei mit Drag 'n Drop auf den Router hochladen.<br />
** [[Datei:Winscp-copy-firmware.jpg]]<br />
* ''Statt WinSCP kann auch [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PSCP] verwendet werden: <tt>pscp -scp -6 <imagename> root@[<ipv6%iface>]:/tmp</tt>''<br />
* Danach loggt man sich via ssh (z.B. mittels [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY]) auf dem Router ein, siehe auch [[Anleitungen|hier]].<br />
* Dann wechselt mit <tt>cd /tmp</tt> in das Verzeichnis wo das Firmware-Image hochgeladen wurde.<br />
* Zuletzt führt man das Update aus: <tt>sysupgrade -n <imagename></tt>. Solange du kein sehr altes Image (vor 0.3.999) auf dem Router hast, kannst du versuchen, ohne <tt>-n</tt> zu flashen, dann bleibt das Passwort erhalten.<br />
<br />
'''Bitte beachten:''' Nach dem Flashen sollte der Router-Hash im Netmon gelöscht werden, damit Router und Netmon einen neuen Hash aushandeln können. Dazu einfach im Netmon einloggen: "Router" (Liste der Router) –> "Routerbezeichnung" (Router ''Bezeichnung'') –> "Routeroptionen" -> "Konfig. bearbeiten" –> "Router auto assign Hash zurücksetzen".<br />
<br />
Der SSH-Fingerprint ändert sich beim Update.<br />
<br />
=== Besonderheiten beim Update ===<br />
==== Besonderheiten beim Update von Ubiquiti Routern von 0.5.0 auf 0.5.1 ====<br />
Es ist nötig, erneut die [https://wiki.freifunk-franken.de/w/Anleitung:UbiquitiPicoStationM2HP#Funktionsweise_der_LAN-Schnittstelle_.C3.A4ndern Funktionsweise der LAN-Schnittstelle] zu konfigurieren.<br />
<br />
Sofern die Netzwerkschnittstelle des Routers als WAN konfiguriert war, wird dringend empfohlen '''vor''' dem Flashen den Router am Heimrouter vom Internet / WAN zu trennen.<br />
<br />
==== Besonderheiten beim Update auf 0.4.0 ====<br />
Wenn bereits 0.4.0rc3f oder neuer installiert ist, einfach mit <tt>sysupgrade</tt> (ohne <tt>-n</tt> Schalter) updaten. Die vorherigen Versionen benötigen zum Flashen noch das <tt>sysupgrade -n</tt> (mit <tt>-n</tt> Schalter). Die alten Images (ab 0.3.999) weisen bei der Verwendung von Sysupgrade bereits auf diesen Umstand hin.<br />
<br />
Einfache Regel: Solange du kein sehr altes Image (vor 0.3.999) auf dem Router hast, versuche, ohne <tt>-n</tt> zu flashen. Sollte die Firmware dies noch nicht unterstützen, meldet sie sich mit einer Fehlermeldung. Es geht ansonsten auch nichts kaputt, wenn du mit <tt>-n</tt> flashst.<br />
<br />
==== Besonderheiten beim Update auf 0.3.999 ====<br />
Durch den geänderten WLAN-Kanal 1 ist nach dem Flashen die Verbindung zu Routern mit der alten Version über Funk nicht mehr möglich. Sollen also Router aus der Ferne upgedated werden, sollte dies beachtet werden. Nach dem Update bitte im Netmon den Router-Hash zurücksetzen.<br />
<br />
==== Besonderheiten beim Update von einer Firmware vor 0.4.0rc4f ====<br />
Gilt nur, wenn auf dem Router eine Firmware vor 0.4.0rc4f installiert ist:<br />
<br />
Beim Sysupgrade bitte mit <tt>-n</tt> flashen, damit die alte Config durch die neue überschrieben wird. Dies ist nötig, damit die Daten nicht falsch vermischt werden und am Ende das Passwort nicht mehr stimmt.<br />
<br />
=== Failsafe-Modus ===<br />
Wenn beim Flashen etwas schiefgegangen ist und der Router nicht mehr antwortet, dann gibt es als Notnagel noch den [http://wiki.openwrt.org/de/doc/howto/generic.failsafe Failsafe-Modus].<br />
# Router einschalten<br />
# Schalter (QSS) jede Sekunde drücken, etwa eine halbe Minute lang, bis die System-Led schnell blinkt<br />
# IP des eigenen Rechners einstellen auf 192.168.1.2<br />
# Telnet auf den Router 192.168.1.1<br />
# Im Telnet-Fenster (auf dem Router) eingeben:<br />
#: <pre>mount_root</pre><br />
#: <pre>passwd</pre><br />
#: <pre>dropbear</pre><br />
# Unter Windows in Cygwin oder unter Linux in der Konsole:<br />
#: <pre>rm .ssh/known_hosts (nur falls sich scp beschwert, dass der Fingerprint nicht stimmt)</pre><br />
#: <pre>scp '/pfad/zur/datei/openwrt-ar71xx-generic-tl-wr841nd-v7-squashfs-factory.bin' root@192.168.1.1:/tmp</pre><br />
# Im Telnet-Fenster (auf dem Router):<br />
#: <pre>sysupgrade -n /tmp/openwrt-ar71xx-generic-tl-wr841nd-v7-squashfs-factory.bin</pre><br />
# Abwarten und den Router '''nicht''' ausschalten, er rebootet von alleine.<br />
<br />
Wenn das nicht geklappt hat, dann schau [http://wiki.openwrt.org/de/doc/howto/generic.debrick hier her].<br />
<br />
Eine schrittweise Anleitungen zum Wiederbeleben eines defekten Routers, der nicht mehr durchstartet gibt es auch hier: <br />
<br />
https://wiki.freifunk-franken.de/w/Unbricken_eines_TP-Link_1043ND<br />
<br />
=== Reflash zur Orginal TP-Link Firmware ===<br />
Eine schöne Anleitung zum Zurück-Flashen eines WR841 gibt es hier im [http://wiki.freifunk-mainz.de/w/Howto/Originalfirmware_zur%C3%BCckflashen Freifunk Mainz Wiki] von ''Antennen-Wolfgang''. Diese Methode funktioniert mit Sicherheit auch mit anderen TP-Link-Modellen. Eine Anleitung für den Router TP 841 mit der Firmware 9.x geht über die Anleitung vom [https://www.freifunk-gera-greiz.de/wiki/-/wiki/Allgemein/WR841N+%3CSLASH%3E+WR841ND Freifunk Gera-Greiz]. Wenn diese Methode angewendet wird und der Router schon im Netmon angelegt war, sollte man ihn vorher dort löschen.<br />
<br />
== Noch eine Bitte ==<br />
Bitte melde dich bei unserer Mailingliste an! Die Infos dazu gibt es unter [[Portal:Kommunikation|Kommunikation]]. Dort gibt es auch Hilfe und Support bei der Installation. Danke!<br />
<br />
== Siehe auch ==<br />
[http://wiki.freifunk.net/Kommandos Kommandoliste auf den Freifunk-Routern]<br />
[[Kategorie:Technik]]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Portal:Firmware_OUT&diff=5053
Portal:Firmware OUT
2015-12-10T18:19:38Z
<p>Green: /* Registrierung/Übernahme im Netmon */</p>
<hr />
<div>= Firmware =<br />
Aktuell ist die Version 0.5.1. https://dev.freifunk-franken.de/firmware/<br />
<br />
Eine Anleitung wie die aktuellen Firmware gebaut wird oder an der Entwicklung teilgenommen werden kann gibt es [[FirmwareEntwicklung|hier]].<br />
<br />
'''Tipp:''' Die Inbetriebnahme eines mit FF-Firmware geflashten Router/Registrierung zum Weitergeben/Ausdrucken als [[media:Anleitung_zur_Inbetriebnahme_eines_Freifunkrouters.pdf|PDF]].<br />
<br />
== Anleitung zur Routerinstallation ==<br />
<br />
für WR841N(D) WR1043N(D)<br />
<br />
=== Auspacken ===<br />
[[Datei:dein_router.jpg|400px|thumb|Lieferinhalt]]<br />
<br />
* Router (1) auspacken, Teile auf Vollständigkeit überprüfen<br />
* falls die Antenne (2) noch nicht angeschlossen ist, schraubt man diese jetzt an<br />
* das Netzteil (3) für die Stromversorgung des Routers und das LAN-Kabel (4) braucht man später<br />
** Es sollte immer das original Netzteil verwendet werden um Probleme wärend dem Flshen zu vermeiden.<br />
<br />
=== Firmware (Erst-)Installation ===<br />
[[Datei:TP_link_version.jpg|400px|thumb|Router Rückseite]]<br />
<br />
* Hier eine [[Portal:Hardware|Liste]], welche Routertypen für die Freifunk-Franken-Firmware geeignet sind<br />
* Herauszufinden, welche Firmware man braucht, ist ganz einfach: der Routertyp (1) und die Hardwareversion (2) stehen auf der Unterseite des Routers.<br />
* Die passende aktuelle Firmware [https://dev.freifunk-franken.de/firmware/current/ hier] herunterladen.<br />
** Die '''Factory'''-Version ist zu verwenden, wenn vorher noch keine Freifunk-Firmware installiert war.<br />
** Die '''Sysupgrade'''-Version braucht man nur, wenn bereits eine Freifunk-Firmware installiert ist.<br />
<br />
<div style="border:1px solid black;"><br />
'''Achtung!''' <br />
Die Firmware für den WR841ND V7 (und nur genau für diesen) ist kaputt. Hier sollte [https://dev.freifunk-franken.de/firmware/dev/20150907_meskal/ diese Firmware] verwendet werden bis ein fix eingespielt wurde. Wurde die falsche Firmware bereits geflasht kann mit folgender Lösung das Problem behoben werden:<br />
* nichts am WAN Port anschließen<br />
* Kein meshfähiges Gerät in der nähe betreiben<br />
* LAN Kabel an einen gelben Port ran und probieren per Locallink drauf zu kommen, eventuell auch die letzte Ziffer der MAC +1 oder -1 rechnen (ich glaub -1) sollte eigentlich dann klappen.<br />
Folgendes Kommando dann am Router ausführen:<br />
<pre><br />
cp /etc/network.tl-wr841nd-v7 /etc/network.tl-wr841n-v7 <br />
</pre><br />
Danach rebooten und der Router sollte sich problemlos im Netmon melden.<br />
</div><br />
<br />
[[Datei:gelbe_buchse.jpg|400px|thumb|gelbe Buchse]]<br />
* den Computer z.B. mit dem beiliegenden Patchkabel an einen der LAN-Ports (gelb) des Routers anschließen<br />
* den Router an Strom anschließen und einschalten<br />
* warten, bis der eigene Computer eine gültige IP-Adresse bekommen hat (Falls dies nicht klappt, den Rechner neu starten und prüfen, ob die IP-Adresse automatisch vom Router bezogen wurde.)<br />
* im Webinterface des Routers einloggen (Nutzername und Passwort stehen auf der Unterseite des Routers; normalerweise funktioniert http://admin:admin@192.168.0.1)<br />
<br />
[[Datei:TP_link_firmware.jpg|400px|thumb|Firmware-Update]]<br />
* unter "System Tools" –> "Firmware Upgrade" die vorher heruntergeladene Firmware zum Gerät schicken<br />
* Geduldig warten, bis der Router neu startet. '''Während die Installation läuft, ziehe bitte auf keinen Fall den Stecker oder das Netzwerk-Kabel!'''<br />
* Im Webinterface kann nach dem Neustart gegebenenfalls die Fehlermeldung kommen, dass keine Verbindung möglich ist. Die neue Firmware hat kein Webinterface.<br />
* Das Passwort sollte geändert werden! Siehe [[Anleitungen|hier]].<br />
<br />
=== Registrierung/Übernahme im Netmon ===<br />
* Router nach dem Firmware Flash nicht manuell booten oder vom Strom trennen<br />
* über den WAN-Port (blau) den Router mit dem Internet verbinden (einfach von gelb auf blau umstecken oder per B.A.T.M.A.N über WLAN mit schon in der Nähe stehenden Freifunkroutern verbinden lassen)<br />
* Router sollte innerhalb der nächsten 5-10 Minuten im Netmon unter Router/Neue Router auftauchen<br />
* auf [https://netmon.freifunk-franken.de/routerlist.php Routerliste] gehen<br />
* auf "Registrieren" klicken (oben rechts)<br />
* Benutzername und Passwort ausdenken und eingeben, E-Mail eingeben, auf Registrieren klicken<br />
* wenn E-Mail da ist, Registrierung abschließen<br />
* neue Router tauchen unter "Router" (Routerliste) –> "[https://netmon.freifunk-franken.de/routers_trying_to_assign.php Neue Router]" auf<br />
* Router übernehmen und Name sowie Position auf Karte eintragen, den Router erkennt man an seiner MAC-Adresse (siehe Aufkleber Unterseite)<br />
<br />
<div style="margin-bottom:1em; padding:1em 1em 0.5em 1em; border:2px solid #dc0067;color:#000;"><br />
<b>Wichtig:</b><br/><br />
Der Ortseintrag im Netmon ist für die korrekte Funktion des Freifunknetzes von hoher Bedeutung.<br />
Das Freifunk-Franken Netz ist in verschiedene Hoods segmentiert (Vgl. [[Portal:Netz]]). Ein in die '''falsche''' Hood oder ein '''nicht''' eingetragener Router, der mit anderen Routern mesht, umgeht die beabsichtigte Segmentierung und verbindet die jeweiligen Hoods auf Level 2 Ebene miteinader, wo jediglich ein Level 3 Routing stattfinden sollte.<br />
<br />
Dies ist die momentan häufigste Ursache für Schwierigkeiten und Performance-Defizite im Freifunk Netz.<br />
<br />
Wer seinen Standort nicht bekannt geben möchte, möge ihn auf der Netmon Karte in der gleichen Hood, in der der Router seinen tatsächlichen Standort hat, an einem beliebigen anderen Ort platzieren.<br />
<br />
Die Aufteilung der Hoods kann man [https://monitoring.freifunk-franken.de/map hier] einsehen, indem man im Overlay (rechte obere Ecke) die Checkbox Hoods aktiviert. <br />
<br />
Gut geeignete Fake-Standorte sind die, die sofort als solche erkannt werden können, z.B.:<br />
* für die Fürther Hood: Mitten im Stadtparkweiher, auf der Pegnitz oder auf der Rednitz<br />
* für die Nürnberger Hood: Mitten auf dem Wöhrder See<br />
* ganz Allgemein: Truppenübungsplätze, Flüsse, Seen, Flughafenrollbahnen, auf der Autobahnmitte, mitten auf dem Fußballplatz<br />
<br />
Die richtige Angabe des tatsächlichen Standorts erachten wir selbstverständlich für vorteilhafter. Wer keinen Standort angeben möchte, möge sich einen beliebigen innerhalb der selben Hood aussuchen.<br />
</div><br />
<br />
== Firmware-Update ==<br />
<br />
Wenn bereits eine Freifunk-Franken-Firmware auf dem Router installiert ist, geht man zum Updaten nach einer der folgenden Methoden vor:<br />
<br />
=== Möglichkeit 1: sysupgrade.sh ===<br />
'''<span style="color:#FF0000">Achtung: Funktioniert erst <u>ab</u> Firmware Version 0.5.1</span>'''<br />
* Man loggt sich auf dem Router per ssh ein, siehe auch [[Anleitungen|hier]].<br />
* Und startet folgendes Skript ''/etc/sysupgrade.sh''<br />
<br />
=== Möglichkeit 2: Skript einfügen ===<br />
* Man loggt sich auf dem Router per ssh ein, siehe auch [[Anleitungen|hier]].<br />
* Man fügt in das Fenster der Konsole dieses Skript ein und bestätigt gegebenenfalls mit [Enter]:<br />
<pre><br />
BOARD=$(cat /var/sysinfo/board_name)<br />
case "$BOARD" in<br />
tl-wr1043nd)<br />
BOARD=tl-wr1043nd-v1<br />
;;<br />
tl-wr741nd)<br />
grep "Atheros AR7240 rev 2" /proc/cpuinfo && BOARD=tl-wr741nd-v2 || BOARD=tl-wr741nd-v4<br />
;;<br />
tl-wr741nd-v4)<br />
grep 740 /var/sysinfo/model && BOARD=tl-wr740n-v4<br />
;;<br />
tl-wr841n-v7)<br />
BOARD=tl-wr841nd-v7<br />
;;<br />
tl-wr841n-v9)<br />
grep "v10" /var/sysinfo/model && BOARD=tl-wr841n-v10<br />
;;<br />
nanostation-m)<br />
BOARD=ubnt-nano-m<br />
;;<br />
tl-wdr4300)<br />
BOARD=tl-wdr4300-v1<br />
;;<br />
esac<br />
FILE="openwrt-ar71xx-generic-$BOARD-squashfs-sysupgrade.bin"<br />
echo "Loading $FILE"<br />
cd /tmp/<br />
wget http://$(uci get configurator.@api[0].ipv6_address)%$(uci get configurator.@api[0].ipv6_interface)/dev/firmware/current/${FILE}<br />
wget http://$(uci get configurator.@api[0].ipv6_address)%$(uci get configurator.@api[0].ipv6_interface)/dev/firmware/current/${FILE}.md5<br />
md5sum -c ${FILE}.md5 && sysupgrade ${FILE}<br />
</pre><br />
<br />
'''Tipp:''' Unter Windows kann der Inhalt der Zwischenablage durch [Umschalt]+[Einfg] in das PuTTY-Konsolenfenster eingefügt werden.<br />
* Bei Ubiquiti Routern ggf. manuell vorgehen (siehe Möglichkeit 3).<br />
<br />
=== Möglichkeit 3: manuelles Vorgehen ===<br />
==== unter Linux ====<br />
* Man loggt sich per ssh auf dem Router ein: <tt>ssh root@<ipv6%iface></tt>, siehe auch [[Anleitungen|hier]].<br />
* Man wechselt mit <tt>cd /tmp</tt> in das richtige Verzeichnis. Das aktuelle Verzeichnis kann man sich mit <tt>pwd</tt> anzeigen lassen.<br />
** Das Image wird auf den lokalen PC heruntergeladen und dann auf den Router hochgeladen, dazu gibst du auf deinem Rechner diesen Befehl in die Linux-Konsole ein: <tt>scp <imagename> root@[<ipv6%iface>]:/tmp</tt>, das sieht dann z.B. so aus: <tt>scp openwrt-ar71xx-generic-tl-wr741nd-v4-squashfs-sysupgrade.bin root@[fe80::fad1:11ff:fe90:3e6e%wlan0]:/tmp</tt><br />
** Alternativ erfolgt der Download direkt auf dem Router <tt>cd /tmp && wget http://[fe80::ff:feee:1%br-mesh]/dev/firmware/<version>/<image></tt>, z.B. <tt>cd /tmp && wget http://[fe80::ff:feee:1%br-mesh]/dev/firmware/0.5.1/openwrt-ar71xx-generic-tl-wr741nd-v4-squashfs-sysupgrade.bin</tt><br />
* Zuletzt führt man das Update aus: <tt>sysupgrade -n <imagename></tt>. Solange du kein sehr altes Image (vor 0.3.999) auf dem Router hast, kannst du versuchen, ohne <tt>-n</tt> zu flashen, dann bleibt das Passwort erhalten.<br />
<br />
==== unter Windows ====<br />
<br />
* Zuerst muss das Firmware-Image (bin-Datei mit dem Wert "sysupgrade" im Namen z.B. <tt>"openwrt-ar71xx-generic-ubnt-nano-m-squashfs-<span style="color:#FF0000">sysupgrade</span>.bin"</tt>) auf den Computer heruntergeladen werden.<br />
* Um die Datei auf den Router spielen zu können muss man sich zuerst mit dem Freifunk-Netz verbinden (via WLAN oder LAN).<br />
* Mit [https://winscp.net/eng/download.php WinSCP] kann man die Datei auf das Gerät kopieren.<br />
** Dazu startet man WinSCP und wählt als Übertragungsprotokoll "SCP", gibt IPv6-Adresse des Routers, sowie "root" als User und das dazugehörige Passwort ein.<br />
** [[Datei:Winscp-connection-settings.jpg]]<br />
** Dann wechselt man im linken Explorer (eigener Rechner) in das Verzeichnis wo man das Image heruntergeladen hat und im rechten Explorer in das Verzeichnis "/tmp". Dann kann man die Datei mit Drag 'n Drop auf den Router hochladen.<br />
** [[Datei:Winscp-copy-firmware.jpg]]<br />
* ''Statt WinSCP kann auch [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PSCP] verwendet werden: <tt>pscp -scp -6 <imagename> root@[<ipv6%iface>]:/tmp</tt>''<br />
* Danach loggt man sich via ssh (z.B. mittels [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY]) auf dem Router ein, siehe auch [[Anleitungen|hier]].<br />
* Dann wechselt mit <tt>cd /tmp</tt> in das Verzeichnis wo das Firmware-Image hochgeladen wurde.<br />
* Zuletzt führt man das Update aus: <tt>sysupgrade -n <imagename></tt>. Solange du kein sehr altes Image (vor 0.3.999) auf dem Router hast, kannst du versuchen, ohne <tt>-n</tt> zu flashen, dann bleibt das Passwort erhalten.<br />
<br />
'''Bitte beachten:''' Nach dem Flashen sollte der Router-Hash im Netmon gelöscht werden, damit Router und Netmon einen neuen Hash aushandeln können. Dazu einfach im Netmon einloggen: "Router" (Liste der Router) –> "Routerbezeichnung" (Router ''Bezeichnung'') –> "Routeroptionen" -> "Konfig. bearbeiten" –> "Router auto assign Hash zurücksetzen".<br />
<br />
Der SSH-Fingerprint ändert sich beim Update.<br />
<br />
=== Besonderheiten beim Update ===<br />
==== Besonderheiten beim Update von Ubiquiti Routern von 0.5.0 auf 0.5.1 ====<br />
Es ist nötig, erneut die [https://wiki.freifunk-franken.de/w/Anleitung:UbiquitiPicoStationM2HP#Funktionsweise_der_LAN-Schnittstelle_.C3.A4ndern Funktionsweise der LAN-Schnittstelle] zu konfigurieren.<br />
<br />
Sofern die Netzwerkschnittstelle des Routers als WAN konfiguriert war, wird dringend empfohlen '''vor''' dem Flashen den Router am Heimrouter vom Internet / WAN zu trennen.<br />
<br />
==== Besonderheiten beim Update auf 0.4.0 ====<br />
Wenn bereits 0.4.0rc3f oder neuer installiert ist, einfach mit <tt>sysupgrade</tt> (ohne <tt>-n</tt> Schalter) updaten. Die vorherigen Versionen benötigen zum Flashen noch das <tt>sysupgrade -n</tt> (mit <tt>-n</tt> Schalter). Die alten Images (ab 0.3.999) weisen bei der Verwendung von Sysupgrade bereits auf diesen Umstand hin.<br />
<br />
Einfache Regel: Solange du kein sehr altes Image (vor 0.3.999) auf dem Router hast, versuche, ohne <tt>-n</tt> zu flashen. Sollte die Firmware dies noch nicht unterstützen, meldet sie sich mit einer Fehlermeldung. Es geht ansonsten auch nichts kaputt, wenn du mit <tt>-n</tt> flashst.<br />
<br />
==== Besonderheiten beim Update auf 0.3.999 ====<br />
Durch den geänderten WLAN-Kanal 1 ist nach dem Flashen die Verbindung zu Routern mit der alten Version über Funk nicht mehr möglich. Sollen also Router aus der Ferne upgedated werden, sollte dies beachtet werden. Nach dem Update bitte im Netmon den Router-Hash zurücksetzen.<br />
<br />
==== Besonderheiten beim Update von einer Firmware vor 0.4.0rc4f ====<br />
Gilt nur, wenn auf dem Router eine Firmware vor 0.4.0rc4f installiert ist:<br />
<br />
Beim Sysupgrade bitte mit <tt>-n</tt> flashen, damit die alte Config durch die neue überschrieben wird. Dies ist nötig, damit die Daten nicht falsch vermischt werden und am Ende das Passwort nicht mehr stimmt.<br />
<br />
=== Failsafe-Modus ===<br />
Wenn beim Flashen etwas schiefgegangen ist und der Router nicht mehr antwortet, dann gibt es als Notnagel noch den [http://wiki.openwrt.org/de/doc/howto/generic.failsafe Failsafe-Modus].<br />
# Router einschalten<br />
# Schalter (QSS) jede Sekunde drücken, etwa eine halbe Minute lang, bis die System-Led schnell blinkt<br />
# IP des eigenen Rechners einstellen auf 192.168.1.2<br />
# Telnet auf den Router 192.168.1.1<br />
# Im Telnet-Fenster (auf dem Router) eingeben:<br />
#: <pre>mount_root</pre><br />
#: <pre>passwd</pre><br />
#: <pre>dropbear</pre><br />
# Unter Windows in Cygwin oder unter Linux in der Konsole:<br />
#: <pre>rm .ssh/known_hosts (nur falls sich scp beschwert, dass der Fingerprint nicht stimmt)</pre><br />
#: <pre>scp '/pfad/zur/datei/openwrt-ar71xx-generic-tl-wr841nd-v7-squashfs-factory.bin' root@192.168.1.1:/tmp</pre><br />
# Im Telnet-Fenster (auf dem Router):<br />
#: <pre>sysupgrade -n /tmp/openwrt-ar71xx-generic-tl-wr841nd-v7-squashfs-factory.bin</pre><br />
# Abwarten und den Router '''nicht''' ausschalten, er rebootet von alleine.<br />
<br />
Wenn das nicht geklappt hat, dann schau [http://wiki.openwrt.org/de/doc/howto/generic.debrick hier her].<br />
<br />
Eine schrittweise Anleitungen zum Wiederbeleben eines defekten Routers, der nicht mehr durchstartet gibt es auch hier: <br />
<br />
https://wiki.freifunk-franken.de/w/Unbricken_eines_TP-Link_1043ND<br />
<br />
=== Reflash zur Orginal TP-Link Firmware ===<br />
Eine schöne Anleitung zum Zurück-Flashen eines WR841 gibt es hier im [http://wiki.freifunk-mainz.de/w/Howto/Originalfirmware_zur%C3%BCckflashen Freifunk Mainz Wiki] von ''Antennen-Wolfgang''. Diese Methode funktioniert mit Sicherheit auch mit anderen TP-Link-Modellen. Eine Anleitung für den Router TP 841 mit der Firmware 9.x geht über die Anleitung vom [https://www.freifunk-gera-greiz.de/wiki/-/wiki/Allgemein/WR841N+%3CSLASH%3E+WR841ND Freifunk Gera-Greiz]. Wenn diese Methode angewendet wird und der Router schon im Netmon angelegt war, sollte man ihn vorher dort löschen.<br />
<br />
== Noch eine Bitte ==<br />
Bitte melde dich bei unserer Mailingliste an! Die Infos dazu gibt es unter [[Portal:Kommunikation|Kommunikation]]. Dort gibt es auch Hilfe und Support bei der Installation. Danke!<br />
<br />
== Siehe auch ==<br />
[http://wiki.freifunk.net/Kommandos Kommandoliste auf den Freifunk-Routern]<br />
[[Kategorie:Technik]]</div>
Green
https://wiki.freifunk-franken.de/mediawiki/index.php?title=Portal:Firmware_OUT&diff=5052
Portal:Firmware OUT
2015-12-10T18:18:17Z
<p>Green: /* Registrierung/Übernahme im Netmon */</p>
<hr />
<div>= Firmware =<br />
Aktuell ist die Version 0.5.1. https://dev.freifunk-franken.de/firmware/<br />
<br />
Eine Anleitung wie die aktuellen Firmware gebaut wird oder an der Entwicklung teilgenommen werden kann gibt es [[FirmwareEntwicklung|hier]].<br />
<br />
'''Tipp:''' Die Inbetriebnahme eines mit FF-Firmware geflashten Router/Registrierung zum Weitergeben/Ausdrucken als [[media:Anleitung_zur_Inbetriebnahme_eines_Freifunkrouters.pdf|PDF]].<br />
<br />
== Anleitung zur Routerinstallation ==<br />
<br />
für WR841N(D) WR1043N(D)<br />
<br />
=== Auspacken ===<br />
[[Datei:dein_router.jpg|400px|thumb|Lieferinhalt]]<br />
<br />
* Router (1) auspacken, Teile auf Vollständigkeit überprüfen<br />
* falls die Antenne (2) noch nicht angeschlossen ist, schraubt man diese jetzt an<br />
* das Netzteil (3) für die Stromversorgung des Routers und das LAN-Kabel (4) braucht man später<br />
** Es sollte immer das original Netzteil verwendet werden um Probleme wärend dem Flshen zu vermeiden.<br />
<br />
=== Firmware (Erst-)Installation ===<br />
[[Datei:TP_link_version.jpg|400px|thumb|Router Rückseite]]<br />
<br />
* Hier eine [[Portal:Hardware|Liste]], welche Routertypen für die Freifunk-Franken-Firmware geeignet sind<br />
* Herauszufinden, welche Firmware man braucht, ist ganz einfach: der Routertyp (1) und die Hardwareversion (2) stehen auf der Unterseite des Routers.<br />
* Die passende aktuelle Firmware [https://dev.freifunk-franken.de/firmware/current/ hier] herunterladen.<br />
** Die '''Factory'''-Version ist zu verwenden, wenn vorher noch keine Freifunk-Firmware installiert war.<br />
** Die '''Sysupgrade'''-Version braucht man nur, wenn bereits eine Freifunk-Firmware installiert ist.<br />
<br />
<div style="border:1px solid black;"><br />
'''Achtung!''' <br />
Die Firmware für den WR841ND V7 (und nur genau für diesen) ist kaputt. Hier sollte [https://dev.freifunk-franken.de/firmware/dev/20150907_meskal/ diese Firmware] verwendet werden bis ein fix eingespielt wurde. Wurde die falsche Firmware bereits geflasht kann mit folgender Lösung das Problem behoben werden:<br />
* nichts am WAN Port anschließen<br />
* Kein meshfähiges Gerät in der nähe betreiben<br />
* LAN Kabel an einen gelben Port ran und probieren per Locallink drauf zu kommen, eventuell auch die letzte Ziffer der MAC +1 oder -1 rechnen (ich glaub -1) sollte eigentlich dann klappen.<br />
Folgendes Kommando dann am Router ausführen:<br />
<pre><br />
cp /etc/network.tl-wr841nd-v7 /etc/network.tl-wr841n-v7 <br />
</pre><br />
Danach rebooten und der Router sollte sich problemlos im Netmon melden.<br />
</div><br />
<br />
[[Datei:gelbe_buchse.jpg|400px|thumb|gelbe Buchse]]<br />
* den Computer z.B. mit dem beiliegenden Patchkabel an einen der LAN-Ports (gelb) des Routers anschließen<br />
* den Router an Strom anschließen und einschalten<br />
* warten, bis der eigene Computer eine gültige IP-Adresse bekommen hat (Falls dies nicht klappt, den Rechner neu starten und prüfen, ob die IP-Adresse automatisch vom Router bezogen wurde.)<br />
* im Webinterface des Routers einloggen (Nutzername und Passwort stehen auf der Unterseite des Routers; normalerweise funktioniert http://admin:admin@192.168.0.1)<br />
<br />
[[Datei:TP_link_firmware.jpg|400px|thumb|Firmware-Update]]<br />
* unter "System Tools" –> "Firmware Upgrade" die vorher heruntergeladene Firmware zum Gerät schicken<br />
* Geduldig warten, bis der Router neu startet. '''Während die Installation läuft, ziehe bitte auf keinen Fall den Stecker oder das Netzwerk-Kabel!'''<br />
* Im Webinterface kann nach dem Neustart gegebenenfalls die Fehlermeldung kommen, dass keine Verbindung möglich ist. Die neue Firmware hat kein Webinterface.<br />
* Das Passwort sollte geändert werden! Siehe [[Anleitungen|hier]].<br />
<br />
=== Registrierung/Übernahme im Netmon ===<br />
* Router nach dem Firmware Flash nicht manuell booten oder vom Strom trennen<br />
* über den WAN-Port (blau) den Router mit dem Internet verbinden (einfach von gelb auf blau umstecken oder per B.A.T.M.A.N über WLAN mit schon in der Nähe stehenden Freifunkroutern verbinden lassen)<br />
* Router sollte innerhalb der nächsten 5-10 Minuten im Netmon unter Router/Neue Router auftauchen<br />
* auf [https://netmon.freifunk-franken.de/routerlist.php Routerliste] gehen<br />
* auf "Registrieren" klicken (oben rechts)<br />
* Benutzername und Passwort ausdenken und eingeben, E-Mail eingeben, auf Registrieren klicken<br />
* wenn E-Mail da ist, Registrierung abschließen<br />
* neue Router tauchen unter "Router" (Routerliste) –> "[https://netmon.freifunk-franken.de/routers_trying_to_assign.php Neue Router]" auf<br />
* Router übernehmen und Name sowie Position auf Karte eintragen, den Router erkennt man an seiner MAC-Adresse (siehe Aufkleber Unterseite)<br />
<br />
<div style="margin-bottom:1em; padding:1em 1em 0.5em 1em; border:2px solid #dc0067;color:#000;"><br />
<b>Wichtig:</b><br/><br />
Der Ortseintrag im Netmon ist für die korrekte Funktion des Freifunknetzes von hoher Bedeutung.<br />
Das Freifunk-Franken Netz ist in verschiedene Hoods segmentiert (Vgl. [[Portal:Netz]]). Ein in die '''falsche''' Hood oder ein '''nicht''' eingetragener Router, der mit anderen Routern mesht, umgeht die beabsichtigte Segmentierung und verbindet die jeweiligen Hoods auf Level 2 Ebene miteinader, wo jediglich ein Level 3 Routing stattfinden sollte.<br />
<br />
Dies ist die momentan häufigste Ursache für Schwierigkeiten und Performance-Defizite im Freifunk Netz.<br />
<br />
Wer seinen Standort nicht bekannt geben möchte, möge ihn auf der Netmon Karte in der gleichen Hood, in der der Router seinen tatsächlichen Standort hat, an einem beliebigen anderen Ort platzieren.<br />
<br />
Die Aufteilung der Hoods kann man [https://monitoring.freifunk-franken.de/map hier] einsehen, indem man im Overlay (rechte obere Ecke) die Checkbox Hoods aktiviert. <br />
<br />
Gut geeignete Fake-Standorte sind die, die sofort als solche erkannt werden können, z.B.:<br />
* für die Fürther Hood: Mitten im Stadtparkweiher, auf der Pegnitz oder auf der Rednitz<br />
* für die Nürnberger Hood: Mitten auf dem Wöhrder See<br />
* ganz Allgemein: Truppenübungsplätze, Flüsse, Seen, Flughafenrollbahnen, auf der Autobahnmitte<br />
<br />
Die richtige Angabe des tatsächlichen Standorts erachten wir selbstverständlich für vorteilhafter. Wer keinen Standort angeben möchte, möge sich einen beliebigen innerhalb der selben Hood aussuchen.<br />
</div><br />
<br />
== Firmware-Update ==<br />
<br />
Wenn bereits eine Freifunk-Franken-Firmware auf dem Router installiert ist, geht man zum Updaten nach einer der folgenden Methoden vor:<br />
<br />
=== Möglichkeit 1: sysupgrade.sh ===<br />
'''<span style="color:#FF0000">Achtung: Funktioniert erst <u>ab</u> Firmware Version 0.5.1</span>'''<br />
* Man loggt sich auf dem Router per ssh ein, siehe auch [[Anleitungen|hier]].<br />
* Und startet folgendes Skript ''/etc/sysupgrade.sh''<br />
<br />
=== Möglichkeit 2: Skript einfügen ===<br />
* Man loggt sich auf dem Router per ssh ein, siehe auch [[Anleitungen|hier]].<br />
* Man fügt in das Fenster der Konsole dieses Skript ein und bestätigt gegebenenfalls mit [Enter]:<br />
<pre><br />
BOARD=$(cat /var/sysinfo/board_name)<br />
case "$BOARD" in<br />
tl-wr1043nd)<br />
BOARD=tl-wr1043nd-v1<br />
;;<br />
tl-wr741nd)<br />
grep "Atheros AR7240 rev 2" /proc/cpuinfo && BOARD=tl-wr741nd-v2 || BOARD=tl-wr741nd-v4<br />
;;<br />
tl-wr741nd-v4)<br />
grep 740 /var/sysinfo/model && BOARD=tl-wr740n-v4<br />
;;<br />
tl-wr841n-v7)<br />
BOARD=tl-wr841nd-v7<br />
;;<br />
tl-wr841n-v9)<br />
grep "v10" /var/sysinfo/model && BOARD=tl-wr841n-v10<br />
;;<br />
nanostation-m)<br />
BOARD=ubnt-nano-m<br />
;;<br />
tl-wdr4300)<br />
BOARD=tl-wdr4300-v1<br />
;;<br />
esac<br />
FILE="openwrt-ar71xx-generic-$BOARD-squashfs-sysupgrade.bin"<br />
echo "Loading $FILE"<br />
cd /tmp/<br />
wget http://$(uci get configurator.@api[0].ipv6_address)%$(uci get configurator.@api[0].ipv6_interface)/dev/firmware/current/${FILE}<br />
wget http://$(uci get configurator.@api[0].ipv6_address)%$(uci get configurator.@api[0].ipv6_interface)/dev/firmware/current/${FILE}.md5<br />
md5sum -c ${FILE}.md5 && sysupgrade ${FILE}<br />
</pre><br />
<br />
'''Tipp:''' Unter Windows kann der Inhalt der Zwischenablage durch [Umschalt]+[Einfg] in das PuTTY-Konsolenfenster eingefügt werden.<br />
* Bei Ubiquiti Routern ggf. manuell vorgehen (siehe Möglichkeit 3).<br />
<br />
=== Möglichkeit 3: manuelles Vorgehen ===<br />
==== unter Linux ====<br />
* Man loggt sich per ssh auf dem Router ein: <tt>ssh root@<ipv6%iface></tt>, siehe auch [[Anleitungen|hier]].<br />
* Man wechselt mit <tt>cd /tmp</tt> in das richtige Verzeichnis. Das aktuelle Verzeichnis kann man sich mit <tt>pwd</tt> anzeigen lassen.<br />
** Das Image wird auf den lokalen PC heruntergeladen und dann auf den Router hochgeladen, dazu gibst du auf deinem Rechner diesen Befehl in die Linux-Konsole ein: <tt>scp <imagename> root@[<ipv6%iface>]:/tmp</tt>, das sieht dann z.B. so aus: <tt>scp openwrt-ar71xx-generic-tl-wr741nd-v4-squashfs-sysupgrade.bin root@[fe80::fad1:11ff:fe90:3e6e%wlan0]:/tmp</tt><br />
** Alternativ erfolgt der Download direkt auf dem Router <tt>cd /tmp && wget http://[fe80::ff:feee:1%br-mesh]/dev/firmware/<version>/<image></tt>, z.B. <tt>cd /tmp && wget http://[fe80::ff:feee:1%br-mesh]/dev/firmware/0.5.1/openwrt-ar71xx-generic-tl-wr741nd-v4-squashfs-sysupgrade.bin</tt><br />
* Zuletzt führt man das Update aus: <tt>sysupgrade -n <imagename></tt>. Solange du kein sehr altes Image (vor 0.3.999) auf dem Router hast, kannst du versuchen, ohne <tt>-n</tt> zu flashen, dann bleibt das Passwort erhalten.<br />
<br />
==== unter Windows ====<br />
<br />
* Zuerst muss das Firmware-Image (bin-Datei mit dem Wert "sysupgrade" im Namen z.B. <tt>"openwrt-ar71xx-generic-ubnt-nano-m-squashfs-<span style="color:#FF0000">sysupgrade</span>.bin"</tt>) auf den Computer heruntergeladen werden.<br />
* Um die Datei auf den Router spielen zu können muss man sich zuerst mit dem Freifunk-Netz verbinden (via WLAN oder LAN).<br />
* Mit [https://winscp.net/eng/download.php WinSCP] kann man die Datei auf das Gerät kopieren.<br />
** Dazu startet man WinSCP und wählt als Übertragungsprotokoll "SCP", gibt IPv6-Adresse des Routers, sowie "root" als User und das dazugehörige Passwort ein.<br />
** [[Datei:Winscp-connection-settings.jpg]]<br />
** Dann wechselt man im linken Explorer (eigener Rechner) in das Verzeichnis wo man das Image heruntergeladen hat und im rechten Explorer in das Verzeichnis "/tmp". Dann kann man die Datei mit Drag 'n Drop auf den Router hochladen.<br />
** [[Datei:Winscp-copy-firmware.jpg]]<br />
* ''Statt WinSCP kann auch [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PSCP] verwendet werden: <tt>pscp -scp -6 <imagename> root@[<ipv6%iface>]:/tmp</tt>''<br />
* Danach loggt man sich via ssh (z.B. mittels [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY]) auf dem Router ein, siehe auch [[Anleitungen|hier]].<br />
* Dann wechselt mit <tt>cd /tmp</tt> in das Verzeichnis wo das Firmware-Image hochgeladen wurde.<br />
* Zuletzt führt man das Update aus: <tt>sysupgrade -n <imagename></tt>. Solange du kein sehr altes Image (vor 0.3.999) auf dem Router hast, kannst du versuchen, ohne <tt>-n</tt> zu flashen, dann bleibt das Passwort erhalten.<br />
<br />
'''Bitte beachten:''' Nach dem Flashen sollte der Router-Hash im Netmon gelöscht werden, damit Router und Netmon einen neuen Hash aushandeln können. Dazu einfach im Netmon einloggen: "Router" (Liste der Router) –> "Routerbezeichnung" (Router ''Bezeichnung'') –> "Routeroptionen" -> "Konfig. bearbeiten" –> "Router auto assign Hash zurücksetzen".<br />
<br />
Der SSH-Fingerprint ändert sich beim Update.<br />
<br />
=== Besonderheiten beim Update ===<br />
==== Besonderheiten beim Update von Ubiquiti Routern von 0.5.0 auf 0.5.1 ====<br />
Es ist nötig, erneut die [https://wiki.freifunk-franken.de/w/Anleitung:UbiquitiPicoStationM2HP#Funktionsweise_der_LAN-Schnittstelle_.C3.A4ndern Funktionsweise der LAN-Schnittstelle] zu konfigurieren.<br />
<br />
Sofern die Netzwerkschnittstelle des Routers als WAN konfiguriert war, wird dringend empfohlen '''vor''' dem Flashen den Router am Heimrouter vom Internet / WAN zu trennen.<br />
<br />
==== Besonderheiten beim Update auf 0.4.0 ====<br />
Wenn bereits 0.4.0rc3f oder neuer installiert ist, einfach mit <tt>sysupgrade</tt> (ohne <tt>-n</tt> Schalter) updaten. Die vorherigen Versionen benötigen zum Flashen noch das <tt>sysupgrade -n</tt> (mit <tt>-n</tt> Schalter). Die alten Images (ab 0.3.999) weisen bei der Verwendung von Sysupgrade bereits auf diesen Umstand hin.<br />
<br />
Einfache Regel: Solange du kein sehr altes Image (vor 0.3.999) auf dem Router hast, versuche, ohne <tt>-n</tt> zu flashen. Sollte die Firmware dies noch nicht unterstützen, meldet sie sich mit einer Fehlermeldung. Es geht ansonsten auch nichts kaputt, wenn du mit <tt>-n</tt> flashst.<br />
<br />
==== Besonderheiten beim Update auf 0.3.999 ====<br />
Durch den geänderten WLAN-Kanal 1 ist nach dem Flashen die Verbindung zu Routern mit der alten Version über Funk nicht mehr möglich. Sollen also Router aus der Ferne upgedated werden, sollte dies beachtet werden. Nach dem Update bitte im Netmon den Router-Hash zurücksetzen.<br />
<br />
==== Besonderheiten beim Update von einer Firmware vor 0.4.0rc4f ====<br />
Gilt nur, wenn auf dem Router eine Firmware vor 0.4.0rc4f installiert ist:<br />
<br />
Beim Sysupgrade bitte mit <tt>-n</tt> flashen, damit die alte Config durch die neue überschrieben wird. Dies ist nötig, damit die Daten nicht falsch vermischt werden und am Ende das Passwort nicht mehr stimmt.<br />
<br />
=== Failsafe-Modus ===<br />
Wenn beim Flashen etwas schiefgegangen ist und der Router nicht mehr antwortet, dann gibt es als Notnagel noch den [http://wiki.openwrt.org/de/doc/howto/generic.failsafe Failsafe-Modus].<br />
# Router einschalten<br />
# Schalter (QSS) jede Sekunde drücken, etwa eine halbe Minute lang, bis die System-Led schnell blinkt<br />
# IP des eigenen Rechners einstellen auf 192.168.1.2<br />
# Telnet auf den Router 192.168.1.1<br />
# Im Telnet-Fenster (auf dem Router) eingeben:<br />
#: <pre>mount_root</pre><br />
#: <pre>passwd</pre><br />
#: <pre>dropbear</pre><br />
# Unter Windows in Cygwin oder unter Linux in der Konsole:<br />
#: <pre>rm .ssh/known_hosts (nur falls sich scp beschwert, dass der Fingerprint nicht stimmt)</pre><br />
#: <pre>scp '/pfad/zur/datei/openwrt-ar71xx-generic-tl-wr841nd-v7-squashfs-factory.bin' root@192.168.1.1:/tmp</pre><br />
# Im Telnet-Fenster (auf dem Router):<br />
#: <pre>sysupgrade -n /tmp/openwrt-ar71xx-generic-tl-wr841nd-v7-squashfs-factory.bin</pre><br />
# Abwarten und den Router '''nicht''' ausschalten, er rebootet von alleine.<br />
<br />
Wenn das nicht geklappt hat, dann schau [http://wiki.openwrt.org/de/doc/howto/generic.debrick hier her].<br />
<br />
Eine schrittweise Anleitungen zum Wiederbeleben eines defekten Routers, der nicht mehr durchstartet gibt es auch hier: <br />
<br />
https://wiki.freifunk-franken.de/w/Unbricken_eines_TP-Link_1043ND<br />
<br />
=== Reflash zur Orginal TP-Link Firmware ===<br />
Eine schöne Anleitung zum Zurück-Flashen eines WR841 gibt es hier im [http://wiki.freifunk-mainz.de/w/Howto/Originalfirmware_zur%C3%BCckflashen Freifunk Mainz Wiki] von ''Antennen-Wolfgang''. Diese Methode funktioniert mit Sicherheit auch mit anderen TP-Link-Modellen. Eine Anleitung für den Router TP 841 mit der Firmware 9.x geht über die Anleitung vom [https://www.freifunk-gera-greiz.de/wiki/-/wiki/Allgemein/WR841N+%3CSLASH%3E+WR841ND Freifunk Gera-Greiz]. Wenn diese Methode angewendet wird und der Router schon im Netmon angelegt war, sollte man ihn vorher dort löschen.<br />
<br />
== Noch eine Bitte ==<br />
Bitte melde dich bei unserer Mailingliste an! Die Infos dazu gibt es unter [[Portal:Kommunikation|Kommunikation]]. Dort gibt es auch Hilfe und Support bei der Installation. Danke!<br />
<br />
== Siehe auch ==<br />
[http://wiki.freifunk.net/Kommandos Kommandoliste auf den Freifunk-Routern]<br />
[[Kategorie:Technik]]</div>
Green